On Sat, Jan 23, 2016 at 02:10:46AM -0500, Peter Olson wrote: [cut]
> > I'm unhappy for two reasons: > > the failure mode of alloca is SIGSEGV or some other malfunction and there is > no way to test for it > > the *buf &= ~0x20; breaks for UTF8 strings. > > Nevermind that the function implicitly references stderr except when it > doesn't. > On a closer look, the major problem I see here is not that *buf &= ~0x20 breaks UTF8, but instead that alloca(3) allocates space on the stack frame of the caller, and could potentially cause a stack-overflow... This would pass unobserved to most eyes. I have also checked that the implementation of alloca(3) in glibc does never return a null-pointer upon failure, thus making very possible to stack-overflow. Nice example :) HND KatolaZ -- [ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ] [ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ] [ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ] [ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ] _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
