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
