4 ms·
The actual bug was using .data() instead of .c_str() when the author needed a C-style string. But yes, avoiding error-prone functions is an equally effective a
by vitus 4y ago
The actual bug was using .data() instead of .c_str() when the author needed a C-style string.
But yes, avoiding error-prone functions is an equally effective approach.
- zabzonk 4y agoc_str and data are now defined to be identical - both return a null-terminated array of char
- HarHarVeryFunny 4y agoI don't think std::vector<char> supports c_str() - presumably you're thinking of std::string ? Of course he could have done: atoi(std::string(vec.data(), vec.size()).c_str()); But I guess he wanted bugs to test against.
- HarHarVeryFunny 4y agoActually just realized these were for-real bugs, not just sanitizer testing. Got to say I've never found much value in sanitizer-type products. Signal-to-noise ratio too small, and frankly it's easier just to write stuff with a bit more care in the first place than have to go looking for bugs. Same goes for debuggers - good for post-mortem analysis of core dumps, but IMO not the most productive tool to track down bugs. Best debugging tool when needed is a few well placed print statements or assert() calls.... Or just a few decades of experience and not creating bugs in the first place!
- gpderetta 4y agoAre you confusing the sanitizers with static analyzers? Sanitizers have little to no false positives. Occasionally they might flag benign errors, but errors nevertheless. You can think of them as adding assertions for you.
- HarHarVeryFunny 4y agoYou're right - was referring to things like Fortify.