> Am 18.10.2019 um 09:30 schrieb Jens Rehsack <rehs...@gmail.com>: > > > >> Am 17.10.2019 um 22:12 schrieb Laurent Bercot <ska-skaw...@skarnet.org>: >> >>> A reasonable detection in configure stage is definitively to prefer. >> >> Not necessarily. It would work, obviously, but would bloat the build. >> Compile-time generated headers are kinda painful to manage, and I'd like >> to keep their number in check. Also, using configure detection would make >> nonposix.h depend on sysdeps.h, and that's a dependency I'd rather avoid. > > Understood. My experience is vice versa, but therefore different > people are good for. > >>> If stack allocation is a must, maybe it can be evaluated whether >>> alloca can be an alternative. >> >> It cannot. alloca is not POSIX, not portable, and not safe. >> And one of the main advantages of stack allocation is that it keeps the >> code *simple*, compact, and easy to read, as opposed to having malloc() >> calls everywhere; using alloca(), which is also a function call, >> forfeits that advantage. > > It's not - and it would be insane if it would ;) > To reasonable allocate on stack, it has to know about it - so it should > be a compiler builtin: > >> DESCRIPTION >> The alloca() macro allocates size bytes of space in the stack frame of >> the caller. This temporary space is automatically freed on return. > > It might not be POSIX, but it might be available where PATH_MAX isn't.
Ah - and wrt. unsafe - yes, especially in C99 variable length array context, which makes C99 preferable over alloca. But it has the same init - dynamically figure out PATH_MAX and initialize the array with it. >> I'll do heap allocation where necessary and where I'm certain that >> stralloc has already been pulled. For the other places, Hurd+skalibs users >> will simply have to avoid ricing their paths. > > As last way out ... > In practice I never encountered FQPN longer than 160 characters. Cheers -- Jens Rehsack - rehs...@gmail.com
signature.asc
Description: Message signed with OpenPGP