Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On Sat, Sep 21, 2013 at 02:46:34PM +0200, Bas Wijnen wrote:
> On Fri, Sep 20, 2013 at 10:12:16PM -0700, Kees Cook wrote:
> > This is absolutely a bug in glibc. While the spec can say "undefined", it
> > is, in fact, not undefined. It worked in a very specific way for over a
> > decade, so that's pretty well defined. ;) The fortify function has no need
> > to change it.
>
> I strongly disagree. If I write a specification for something and an
> implementation of it, then the specification is what defines the behavior. If
> something is not defined, or even explicitly "undefined", then that doesn't
> mean I have to make sure the implementation regularly changes just to make sure
> that I don't give users the "right" to use undefined features.
>
> Code that does undefined things is buggy, even if it works on some
> implementation, and no matter how long it has worked.
In a theoretical sense, sure. In this particular case, why bother breaking
it when it's a trivial 1 line fix? My original approach was to fix it in
libc and do a mass bug filing. Everyone wins. If we want to reject the
undefined behavior, we should modify the compiler to reject it. Seems to me
it's a bug to even allow undefined behavior.
-Kees
--
Kees Cook @debian.org
Reply to: