> 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. > 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
