tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: alloca again



On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote:
 > > This is the current alloca definition in the libc headers:
 > > 
 > > #if defined(_NETBSD_SOURCE)
 > > #if defined(alloca) && (alloca == __builtin_alloca) && \
 > 
 > According to my knowledge of the C preprocessor, the condition 'alloca
 > == __builtin_alloca' always evaluates to '0 == 0', assuming that if
 > 'alloca' and '__builtin_alloca' are actually defined, they expand to
 > some other identifier. As C90 6.8.1 and C99 6.10.1p4 both say, "all
 > remaining identifiers are replaced with the pp-number 0."
 > 
 > Did this condition make any sense at any time in the last 40 years? If
 > not, why has this piece of clearly broken code survived since 1993-03-25?

Note that the part you didn't quote is
   defined(__GNUC__) && __GNUC__ < 2
and all it does is change the argument type to int from size_t.

This makes it highly unlikely that it ever failed, for an assortment
of reasons, not the least of which is that we removed critical parts
of gcc2 support from /usr/include years ago so it's not been exercised
in at least that long.

As for why nobody ever noticed, I'm sure many people have looked at it
and said to themselves "alloca is magic, I'm sure it's that way for a
reason" and not thought about it further. And as Mouse pointed out,
it's definitely possible that it behaves as intended in gcc2's
preprocessor. gcc's handling of builtins in those days was a lot
dodgier than it is now.

Anyway, the gcc2 part can definitely be removed at this point.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index