This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use malloca instead alloca

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]