Paul's points are valid as a generic thing. But they aren't the key points for considering changes to libc.
The entire discussion about maximum usable size is unnecessary fritter. We already have __libc_use_alloca, alloca_account, etc. (include/alloca.h) to govern that decision for libc code. If people want to discuss changing that logic, they can do that separately. But we will certainly not have more than one separate implementation of such logic in libc. Extending that internal API in some fashion to make it less work to use would certainly be welcome. That would have to be done in some way that doesn't add overhead when existing uses of __libc_use_alloca are converted to the new interface. The simplest way to do that would be a macro interface that stores to a local bool, which is what the users of __libc_use_alloca mostly do now. It would be nice to have an interface that is completely trivial to use like malloca is, but for code inside libc that ideal is less important than making sure we do not degrade the performance (including code size) of any of the existing uses. There are a few existing uses of alloca that use their own ad hoc code instead of __libc_use_alloca (misc/err.c, sunrpc/auth_unix.c, maybe others). Those should be converted to use __libc_use_alloca or whatever nicer interface is figured out. Then there are the existing uses of alloca that don't use __libc_use_alloca at all, such as argp/argp-help.c. Those should probably be converted as well, though in some situations like the argp ones it's a bit hard to imagine their really being used with sizes large enough to matter. Thanks, Roland
