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

[Florian Weimer <fweimer at redhat dot com>]

On 01/04/2016 07:50 PM, Paul Eggert wrote:
> 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?

I believe the old way of implementing alloca (with a direct stack
pointer manipulation) was never well-defined and was unreliable in the
presence of optimization.  But all the evidence I have is an old GCC
INSTALL file which lists many platforms which have alloca, but where it
is subtly broken and had to be disabled/worked around.  Back then, such
issues were deemed acceptable, including application workarounds.

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

I've asked, the exact version is not known.  The restriction is
necessarily gone since the switch to tree-ssa.

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

I very much doubt there is a single compiler which can process the glibc
header files and does not define __GNUC__.  I found an Intel manual
which says that the system header files do not compile correctly when
__GNUC__ is not defined.  Which wouldn't be surprising at all because we
do not test this.  The Pathscale compiler defines __GNUC__ as well,
according to its manual.  Even Nvidia's OpenCC compiler does it.

Florian