Le 13/07/2025 à 16:39, c8ef a écrit :
Hi all,
I'm currently working on implementing the `split` procedure, which was
added in Fortran 2023. Given its similar functionality to the `scan`
intrinsic, I've been learning the implementation of `scan` to better
understand its mechanics. During my investigation of the source code,
I've come across a couple of questions that I'm hoping you could help me
out:
* Function Resolution
I noticed that `scan` resolves to `gfc_get_string("__scan_%d", string-
>ts.kind)`. However, based on my examination of `libgfortran` and
`trans-intrinsic.cc`, it appears this ultimately forwards to the
`string_scan` function. Could you please explain the significance of
this resolution step? Is it critical to the current implementation, or
is it perhaps a remnant of historical design?
No, it's not critical; I think the name can be used in compile-time
errors for example. The name that really matters is the name of the
function declaration that is passed to the middle-end (look for
string_scan in trans-decl.cc). Note that there are two variants:
string_scan, and string_scan_char4 (both on the front-end size and in
libgfortran).
* Argument Passing
According to the Fortran specification, the `scan` intrinsic accepts
arguments for `string`, `set`, `back`, and `kind`. Yet, the intrinsic
implemented in `libgfortran` seems to take `charlen` and the actual
pointers for both `string` and `set`. I've tried searching, but I
haven't been able to pinpoint where this transformation from the
specified arguments to the `libgfortran` expected arguments occurs. Any
guidance on this would be greatly appreciated.
You can have a look in gfc_conv_intrinsic_function_args.
To arrive there, the call stack starts with gfc_conv_expr (the main
expression translation entry point), then gfc_conv_function_expr,
gfc_conv_intrinsic_function, there jump to the GFC_ISYM_SCAN switch
case, then gfc_conv_intrinsic_index_scan_verify and finally
gfc_conv_intrinsic_function_args.
I hope it helps.
