Re: [PATCH v2 4/5] alloca.3: remove GCC faffling from NOTES

["Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>]

Hi наб,

On 9/17/21 10:45 PM, наб wrote:
> On Wed, Sep 15, 2021 at 09:48:14PM +0200, Alejandro Colomar (man-pages) wrote:
>> On 9/14/21 2:41 PM, наб wrote:
>> [...]
>>> +is required, lest a symbol dependency be emitted.
>> Sorry that I'm not a native English speaker.  I tried to learn what "lest"
>> means, but it's difficult to me, and I'm not sure I understand this line.
>> Could you maybe please reword it?  :)
> 
> I stand by the "lest" version because it gets less noodly,
> but rewritten as "in which case a symbol dependency will be emitted
> unless <alloca.h> is included", see updated scissor-patch below.


Hmm, the wording with 'lest' seems more precise, now that I learnt what 
it means.  I applied the first version.  I also applied the rest of the 
patches in this set (v1).

Thanks,

Alex

> 
> And, well, neither am I, but that's hardly here or there.
> 
> -- >8 --
> Chunks of glibc headers have no place in documenting an interface,
> and (__builtin_)alloca() is an intrinsic, not code; those days are,
> thankfully, long gone
> 
> Also, clarify standards behaviour (and remove the (outdated!)
> list of cc(1) switches) regarding when alloca() is allowed to not be
> ODR-usable
> 
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@nabijaczleweli.xyz>
> ---
>   man3/alloca.3 | 52 +++++++++++++++------------------------------------
>   1 file changed, 15 insertions(+), 37 deletions(-)
> 
> diff --git a/man3/alloca.3 b/man3/alloca.3
> index 20761b079..913cbe56a 100644
> --- a/man3/alloca.3
> +++ b/man3/alloca.3
> @@ -122,46 +122,24 @@ Do not attempt to
>   .BR free (3)
>   space allocated by
>   .BR alloca ()!
> -.SS Notes on the GNU version
> -Normally,
> -.BR gcc (1)
> -translates calls to
> +.PP
> +By necessity,
>   .BR alloca ()
> -with inlined code.
> -This is not done when either the
> -.IR "\-ansi" ,
> -.IR "\-std=c89" ,
> -.IR "\-std=c99" ,
> -or the
> -.IR "\-std=c11"
> -option is given
> -.BR and
> -the header
> -.I <alloca.h>
> -is not included.
> -Otherwise, (without an \-ansi or \-std=c* option) the glibc version of
> -.I <stdlib.h>
> -includes
> +is a compiler built-in, also known as
> +.BR __builtin_alloca ().
> +By default, modern compilers automatically translate all uses of
> +.BR alloca ()
> +into the built-in, but this is forbidden if standards conformance is requested
> +.RI ( "\-ansi" ,
> +.IR "\-std=c*" ),
> +in which case a symbol dependency will be emitted unless
>   .I <alloca.h>
> -and that contains the lines:
> -.PP
> -.in +4n
> -.EX
> -#ifdef  __GNUC__
> -#define alloca(size)   __builtin_alloca (size)
> -#endif
> -.EE
> -.in
> +is included.
>   .PP
> -with messy consequences if one has a private version of this function.
> -.PP
> -The fact that the code is inlined means that it is impossible
> -to take the address of this function, or to change its behavior
> -by linking with a different library.
> -.PP
> -The inlined code often consists of a single instruction adjusting
> -the stack pointer, and does not check for stack overflow.
> -Thus, there is no NULL error return.
> +The fact that
> +.BR alloca ()
> +is a built-in means it is impossible to take its address
> +or to change its behavior by linking with a different library.
>   .SH BUGS
>   Due to the nature of the stack, it is impossible to check if the allocation
>   would overflow the space available, and, hence, neither is indicating an error.
> 


-- 
Alejandro Colomar
Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/