Excerpts from Iain Sandoe's message of August 11, 2025 12:33 am:
> Tested on x86_64-darwin (i.e. that the string is now seen as a regular
> c-string and placed in the appropriate section).
> OK for trunk?
> thanks
> Iain
>
> --- 8< ---
>
> In this function, we are generating a string constant but do so with
> a mismatch between the actual string length and the length specified
> in the type. This causes Darwin, at least, to place the string in an
> unexpected section (since the parameters do not match, it is rejected
> as a cstring).
>
> The change here makes the parameters match on the assumption that it
> is intended to be a null-terminated cstring. Looking through other
> cases where build_string() is used, it seems that some of them are
> not null-terminated.
Places where it is not null terminated would be mostly for use in
dynamic array literals, which have a .length field to tell runtime where
the string stops. Static arrays with a compile-time known length can
get away without having a null-termination too.
Having a look again at this, its the only place I can see that returns a
`const char*` literal, so requires the null-terminator to be emitted.
I suspect these four lines could even be replaced with
return build_string_literal (filename);
As it seems to be equivalent to what was attempted here.
No preference over whether you go for `length + 1` or
build_string_literal, both are OK.
Regards,
Iain.
