> Am 17.10.2019 um 22:12 schrieb Laurent Bercot <ska-skaware_at_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 - rehsack_at_gmail.com
Received on Fri Oct 18 2019 - 07:30:04 UTC