Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
Steve M. Robbins wrote:
> On September 21, 2013 09:04:23 PM Bernhard R. Link wrote:
> > The whole point of undefined behaviour in C is that the
> > compiler/implementor/... does not have to care.
>
> I strongly suspect the "whole point" of undefined behaviour is simply that at
> least two parties on the committee simply couldn't agree on "correct"
> behaviour.
You're completely wrong. It's not like there would be multiple plausible
ways to define a fixed result in this case; the choice is between
requiring the implementation to handle this special case or not, and
they chose to not require it. And in cases where there's a plausible
choice of "correct" behavior, implementation-defined behavior makes a
lot more sense than undefined behavior.
> > Checking every time would
> > make it slower,
>
> What are you referring to as "it"? The compiler? Checking that two arguments
> to a function are the same doesn't strike me as terribly expensive.
The compiler could issue a diagnostic if it can detect that the values
of two arguments are the same, and this would detect some of the obvious
cases mentioned earlier in the thread. But in general it's not possible
to detect this without adding extra runtime checks. For example, if the
program has a function my_sprintf that in turn calls sprintf, the
compiler can't warn about the call to sprintf in my_sprintf since the
validity of that depends on what arguments my_sprintf is called with,
and it can't warn about calls to my_sprintf since it doesn't know those
should avoid giving the same argument twice (at least unless some kind
of global whole-program optimization is used that allows the compiler to
see all the code at once).
> > requesting any specific behaviour would make it slower.
>
> Nonsense -- it has a specific behaviour now.
It does not have specific behavior now. You shouldn't assume that every
possible undocumented implementation detail in some versions of a
library is specified behavior that will keep working the same way
forever.
> Since the standard says it is
> undefined, there's nothing stopping us from reverting back to its old behaviour
> which, arguably, better mached people's expectations -- else they wouldn't
> have written the "buggy" code. Moreover, it is the same behaviour used when
> NOT compiled with _FORTIFY_SOURCE=2.
"else they wouldn't have written the buggy code" is a poor argument -
people write lots of buggy code based on completely nonsensical
assumptions and expectations. Trying to keep the buggy code silently
working is the worst choice, and will just worsen the situation. Any
attempts to keep it working should at least ensure there is a visible
diagnostic, to prevent the creation of more such bugs and give a chance
to fix the existing ones.
Reply to: