Hacker News Reader

Comment by rdtsc | Hacker News Reader

Just curious, does anyone run with _FORTIFY_SOURCE=3 in production? Did you catch any overflows because of it, and most importantly, is there a noticeable performance degradation?

View on HN

Arch Linux switched to it last year

https://rfc.archlinux.page/0017-increase-fortification-level...

Thanks, that’s encouraging. I think I will give it a try in my own projects.

This brings up a question. I think we can all agree that detecting an overrun shows a fault in the system. But does it create an error?

Could this could be changed to where the overflow does not cause an abort; rather the next read of that location, without a corresponding legal write causes the abort. A buffer overrun does not mean the answer is wrong, but the use of memory that was overrun will.

In that case, production or not, you would want an abort. The answer is wrong!

(Perhaps this makes no sense. If so, sorry, the idea just came to me after reading the article.)

Overrunning the buffer means your program's behaviour is undefined. Continuing to function at all, much less doing what you wanted, merely means you got lucky with the compiler this time.

I tend to argue that continuing to function after a memory overrun is _unlucky_ because it's better to have it fail loudly so you know to fix it instead of it potentially not noticing subtly incorrect behavior.

It's also much easier to fix when you know where the overrun occurs compared to getting an abort on a random access later.

Yes, a segfault with a core dump at the point the bug happens is always the optimal scenario.

Reply on news.ycombinator.com