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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130921150813.ga21...@outflux.net
