On Thu, 31 Jul 2025 23:02:20 +0200 Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
> >> This code is just wrong. %zu expects size_t but the argument is > >> ptrdiff_t That is indisputable. In this case, we know args.data() < p, so the difference will never be negative, and the high bit always zero. But, sure. Jakub provided a patch that uses %td instead. Having labored in C++ in relative isolation for decades, I never developed the reflex to think in terms of ptrdiff_t. 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. > this was all described in excruciating detail in the patch submission > > https://gcc.gnu.org/pipermail/gcc-patches/2025-June/687385.html Not ... to my satisfaction? I don't understand the assertion in the commit message: > 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.) Either %zu is valid on all platforms for diagnostic messages or, for some reason, good or bad, it's not. If it is, then I know what to code against. If it's not, then at least I need to know when it's not. 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. --jkl
