tech-userlevel archive

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

Re: alloca again



>>> I'd argue that providing alloca(3) as anything except a compiler
>>> builtin is a bug, and that kind of thing should never be used.
>> I'd argue that alloca should never be used and actually should never
>> have existed.  As far as I can see it does nothing that can't be
>> done better - more portably and correctly - by variable-sized
>> arrays.  Am I missing something?
> I look forward to you fixing every piece of third-party code using it
> in the wild. :)

That sounds like a "no" to my question (which was independent of what
does or doesn't try to use alloca).  Is it?

I don't see any reason I should be responsible for fixing other
people's nonportable code.  (Nor, for that matter, do I see any reason
NetBSD should be responsible for supporting their choices of
nonportabilities.  I consider code that uses alloca() to be on a par
with code that uses, say, SCM_SECURITY ancillary data, sys$crmpsc(), or
#pragma aux: it's choosing to use a nonportable feature.)

Would you have reacted the same if I'd argued against support for, say,
the routines typically declared by <conio.h>?  Why or why not?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index