[PATCH v12 03/25] gas: implement parsing of object attributes v2

[Jan Beulich]

On 22.01.2026 13:53, Matthieu Longo wrote:
> On 22/01/2026 11:00, Jan Beulich wrote:
>> On 19.01.2026 12:32, Jan Beulich wrote:
>>> On 16.01.2026 19:59, Matthieu Longo wrote:
>>>> +  /* If it is neither a string nor an identifier, it must be an expression.  */
>>>> +  bool signedness_issue = false;
>>>> +  bool success = extract_integer_literal (arg_out,
>>>> +					  (low_ttype & UNSIGNED_INTEGER),
>>>> +					  &signedness_issue);
>>>> +  if (success && (low_ttype & (UNSIGNED_INTEGER | SIGNED_INTEGER)))
>>>> +    return true;
>>>> +
>>>> +  char sbuffer[100];
>>>> +  if (success)
>>>> +    as_bad (_("unexpected integer '%lu', expected %s instead"),
>>>> +	    arg_out->val.u64,
>>>
>>> As indicated before, %lu and alike aren't suitable to print uint64_t values.
>>
>> So despite me pointing out this issue here and in other instances, you committed
>> one or more patches with the issue unaddressed, now tripping up the builder:
>>
>> ../../binutils-gdb/bfd/elf-attrs.c: In function ‘_bfd_obj_attr_v2_tag_to_string’:
>> ../../binutils-gdb/bfd/elf-attrs.c:392:36: error: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘obj_attr_tag_t’ {aka ‘long long unsigned int’} [-Werror=format=]
>>    392 |   return xasprintf ("Tag_unknown_%lu", tag);
>>        |                                  ~~^   ~~~
>>        |                                    |   |
>>        |                                    |   obj_attr_tag_t {aka long long unsigned int}
>>        |                                    long unsigned int
>>        |                                  %llu
>> cc1: all warnings being treated as errors
>> make[3]: *** [Makefile:1763: elf-attrs.lo] Error 1
>> make[3]: *** Waiting for unfinished jobs....
> 
> I am going to publish a fix for it.
> FYI I am not detecting any of those issues on my machine, and I am struggling to spot them by reading the source.
> If you know a tool to detect such issues, please let me know.

I don't. The only way that I know to spot at least some is to build on a
32-bit system. But there's a rule of thumb anyway: When you write format
strings, pay attention to the actual types of the variables. And this
going as far as: If already you use fixed-width types, also use their
corresponding formatting #define-s (PRI...). Or, as suggested elsewhere,
try to stick to basic types where possible.

Jan