>>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
