> Am 18.10.2019 um 09:30 schrieb Jens Rehsack <rehsack_at_gmail.com>:
>
>
>
>> 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.
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 - rehsack_at_gmail.com
Received on Fri Oct 18 2019 - 07:34:24 UTC