On Fri, Aug 01, 2025 at 01:32:47PM -0400, James K. Lowden wrote:
> As I said, the pointer arithmetic in this case will disappear. I intend
> to modify the function that now returns a pointer to return size_t,
> because that's what std::vector::operator[] accepts. In my mind the
> question remains, then, whether or not %zu will be ok and, if not, why
> not.
When the argument type changes from ptrdiff_t to size_t, in a gcc_tdiag
function like err_msg sure, you can change that %td to %zu (the d vs. u
doesn't need to match the signedness of ptrdiff_t and size_t btw, %tu
and %zd are fine as well, those print the ptrdiff_t value as if it it was
make_unsigned<ptrdiff_t> or make_signed<size_t>).
On most hosts, size_t and ptrdiff_t are unsigned/signed variants of the
same type (say int, long, long long), only on a few like that 32-bit Darwin
have unsigned long int (32-bit) as size_t and int (32-bit) as ptrdiff_t.
> > hwint.h selects %u
>
> because afaik hwint.h is not involved. The processing of the format
> string for the diagnostics messages is done within gcc, under our
> control by the diagnostics functions, and %zu is a documented valid
> format character. (Yes, it's incorrect here, but that is not my point
> or my question.)
But it being incorrect was the reason why it has been changed by Rainer.
> I don't want to work against anyone. I just want to understand what
> the actual restriction is, if any, and why it can't be addressed
> portably.
The only restriction is that we shouldn't use z/t modifiers in *printf
family because some hosts don't support that, and similarly e.g. %lld
isn't guaranteed to work everywhere (Windows at least had some %I64d
or what). And obviously w modifier is GCC specific and so only gcc_tdiag
(ditto other GCC specifics like q modifier, D, E, T format specifiers,
etc.).
Jakub
