Re: [PATCH 2/2] Fortran: f_c_string intrinsic improvements

Sandra Loosemore wrote:
> The existing implementation of f_c_string is quite inefficient, doing
> either 2 or 3 allocations and copies of the input string prefix.  This
> rewrite adds folding for constant string arguments and handles other
> cases with a single allocation and copy.
> 
> This patch also adds the missing documentation for this intrinsic to the
> gfortran manual.

Thanks for the patch. LGTM, I have one .texi comment, however:

> @@ -3558,6 +3559,7 @@ Fortran 2023 and later.
>   @ref{C_LOC}, @*
>   @ref{C_F_POINTER}
>   @ref{C_F_PROCPOINTER}
> +@ref{F_C_STRING}
>   @end table

I noticed that the others use ', @*'. In 'info' it displays
currently as:

_See also_:
      *note C_ASSOCIATED::,
      *note C_LOC::,
      *note C_F_POINTER::,
      *note C_F_PROCPOINTER:: *note F_C_STRING::


While in the PDF version:

See also:  Section 8.56 [C ASSOCIATED], page 155,
            Section 8.61 [C LOC], page 160,
            Section 8.57 [C F POINTER], page 156,
            Section 8.58 [C F PROCPOINTER], page 157, Section 8.112 [F C 
STRING], page 195,

which is comma wise fine (seems as if a comma always gets added, like 
the superfluous tailing one). For consistency, I think it would be good 
to if all followed the same pattern.

* * *

As an observation:
> +	  gfc_char_t *buf
> +	    = (gfc_char_t *) alloca ((orig_len + 1) * sizeof (gfc_char_t));

Let's hope that the original string isn't megabytes of DNA sequencing
data, exhausting the stack memory due to 'alloca'. On the other hand,
Fortran users are used to 'ulimit -s unlimited', such that there is
probably/hopefully be not a real problem with this.

Thanks again for the cleanup + adding the missing documentation!

Tobias