Hi Arthur,
> On 18 Jan 2024, at 10:30, Arthur Cohen <arthur.co...@embecosm.com> wrote:
> On 1/18/24 10:13, Rainer Orth wrote:
>> Arthur Cohen <arthur.co...@embecosm.com> writes:
>>> Using %lu to format size_t values breaks 32 bit targets, and %zu is not
>>> supported by one of the hosts GCC aims to support - HPUX
>> But we do have uses of %zu in gcc/rust already!
>>> diff --git a/gcc/rust/expand/rust-proc-macro.cc
>>> b/gcc/rust/expand/rust-proc-macro.cc
>>> index e8618485b71..09680733e98 100644
>>> --- a/gcc/rust/expand/rust-proc-macro.cc
>>> +++ b/gcc/rust/expand/rust-proc-macro.cc
>>> @@ -171,7 +171,7 @@ load_macros (std::string path)
>>> if (array == nullptr)
>>> return {};
>>> - rust_debug ("Found %lu procedural macros", array->length);
>>> + rust_debug ("Found %lu procedural macros", (unsigned long)
>>> array->length);
>> Not the best way either: array->length is std::uint64_t, so the format
>> should use
>> ... %" PRIu64 " procedural...
>> instead.
>> I've attached my patch to PR rust/113461.
>
> Yes, I was talking about this on IRC the other day - if we do run in a
> situation where we have more than UINT32_MAX procedural macros in memory we
> have big issues. These debug prints will probably end up getting removed soon
> as they clutter the output a lot for little information.
>
> I don't mind doing it the right way for our regular prints, but we have not
> been using PRIu64 in our codebase so far, so I'd rather change all those
> incriminating format specifiers at once later down the line - this patch was
> pushed so that 32bit targets could bootstrap the Rust frontend for now.
For the sake of completeness, the issue does not just affect 32b hosts; If a
64b host chooses (as Darwin does, so that 32b and 64b targets have the same
representation) to make uint64_t “unsigned long long int”, then %lu breaks
there too.
thanks
Iain
