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 ]