Re: [PATCH] manual: Update alloca and variable length array documentation

[Paul Eggert <eggert at cs dot ucla dot edu>]

Thanks for doing that. It mostly looks good. Some comments:

> -Do not use @code{alloca} inside the arguments of a function call---you
> -will get unpredictable results, because the stack space for the
> -@code{alloca} would appear on the stack in the middle of the space for
> -the function arguments.  An example of what to avoid is @code{foo (x,
> -alloca (4), y)}.
> -@c This might get fixed in future versions of GCC, but that won't make
> -@c it safe with compilers generally.

Although alloca is safe with GCC nowadays, is it known to be safe with 
all compilers? It would be more conservative to replace the above with 
something like the following. It might also be helpful to document the 
GCC version number that fixed this problem, if that version number is known.


Traditionally, @code{alloca} could not be used portably inside the 
arguments of a function call, because the space for the @code{alloca} 
could be allocated on the stack in the middle of the space for the 
function arguments. This problem no longer exists for GCC and compatible 
compilers.


>   @include strdupa.c.texi
>   ...
> -This function is only available if GNU CC is used.
> -
> -@code{strndupa} is only available if GNU CC is used.
>   @end deftypefn

These two macros are protected by "#if defined __USE_GNU && defined 
__GNUC__", no? So they are available only in GCC-compatible compilers. 
Perhaps replace the two copies of the sentence with something like "This 
macro is a GNU extension and is available only with GCC and compatible 
compilers."?