[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
Main Index |
Thread Index |