[PATCH] Fix some more C23 const-correctness issues

[Andrew Burgess]

Jan Beulich <jbeulich@suse.com> writes:

> On 07.01.2026 18:36, Keith Seitz wrote:
>> Fedora Rawhide is failing to build due to new glibc header changes
>> enforcing const-correctness in functions like strchr and memchr.
>> For example:
>> 
>> ../../opcodes/aarch64-dis.c: In function ‘remove_dot_suffix’:
>> ../../opcodes/aarch64-dis.c:4027:7: error: assignment discards ‘const’ qualifier from po
>> inter target type [-Werror=discarded-qualifiers]
>>  4027 |   ptr = strchr (inst->opcode->name, '.');
>>       |       ^
>> cc1: all warnings being treated as errors
>> 
>> This patch addresses all the discovered issues with --enable-targets=all
>> and regenerates a few cgen files along the way.
>
> It's actually not all that many, surprisingly. Otoh --enable-targets=all
> wouldn't cover most of gas/config/*. Most of the changes are okay (if not
> to say "count as obvious"), but ...
>
>> --- a/opcodes/riscv-dis.c
>> +++ b/opcodes/riscv-dis.c
>> @@ -110,7 +110,7 @@ parse_riscv_dis_option_without_args (const char *option,
>>  /* Parse RISC-V disassembler option (possibly with arguments).  */
>>  
>>  static void
>> -parse_riscv_dis_option (const char *option, struct disassemble_info *info)
>> +parse_riscv_dis_option (char *option, struct disassemble_info *info)
>>  {
>>    char *equal, *value;
>
> ... the removal of const here isn't nice. Imo the code would better be
> adjusted to avoid the writing through "equal" (which looks to be possible
> without going through hoops), but let's see whether the RISC-V maintainers
> (now Cc-ed) take a different position.

Not a RISC-V binutils maintainer, but my unsolicited opinion anyway:

parse_riscv_dis_option is only called from parse_riscv_dis_options which
takes a 'const char *' and makes a copy because parse_riscv_dis_options
already modifies the copy during parsing.  It feels like the having
parse_riscv_dis_option take 'const char *' was always a bug.  The
comment on parse_riscv_dis_option should probably have mentioned that
the incoming string will be modified.

I agree that we _could_ rewrite this to be smarter avoiding the strdup
in parse_riscv_dis_options, and the subsequent modifications to the
copy, but (IMHO) that reworking should be done separately to fixing the
real compilation error we're hitting right now.

For what it's worth, I'd vote to take the patch as proposed, but if
someone wanted to rewrite the option parsing to avoid the strdup, I'd
also think that was a great idea.

Thanks,
Andrew