On 7/2/23 12:32, Ben Boeckel wrote:
> When passing `-o` flags to other options, the typical `-o foo` spelling
> leaves a leading whitespace when replacing elsewhere. This ends up
> creating flags spelled as `-some-option-with-arg= foo.ext` which doesn't
> parse properly. When attempting to make a spec function to just remove
> the leading whitespace, the argument splitting ends up masking the
> whitespace. However, the intended extension *also* ends up being its own
> argument.

Odd.  I looked into this to figure out what was going on, and now I 
understand: when process_brace_body handles e.g. %{o*:-fjoined=%.x%*}, 
first it replaces $* with the rest of the flag, i.e. "", resulting in 
-fjoined=, and then adds the argument as a separate argument to the 
result of substitution.  This seems strange, but works fine for the 
existing uses that build one Separate switch from another.

The other oddity you mention comes from

>   /* End of string.  If we are processing a spec function, we need to                                                               
>      end any pending argument.  */
>   if (processing_spec_function)
>     end_going_arg ();

so that when give_switch calls do_spec_1 twice for the basename and 
suffix, they end up as separate arguments to the spec function.  I don't 
know the purpose of this code; it doesn't seem to have been necessary 
for the if-exists spec function that was added in the same patch 
(r59241).  Removing this doesn't seem to break anything for me.

The join function works around both of these issues.  But I notice that 
the use of reconcat is a memory leak, and since we have the obstack 
available I've tweaked the function to use it.  I also added some 
documentation.

Joseph, any thoughts on these issues or the workaround?

Jason