acceptable diagnostic format characters

[Jonathan Wakely]

On Thu, 31 Jul 2025, 22:23 James K. Lowden, <jklowden@cobolworx.com> wrote:

> I want to understand what our baseline is wrt %z in diagnostic
> messages.  The proximate cause is this change on July 11 for 32-bit
> Darwin to gcc/cobol/parse.y:
>
>    error_msg(loc, "FUNCTION %qs has "
> -            "inconsistent parameter type %zu (%qs)",
> -            keyword_str($1), p - args.data(), name_of(p->field) );
>

This code is just wrong. %zu expects size_t but the argument is ptrdiff_t



+            "inconsistent parameter type %ld (%qs)",
> +            keyword_str($1), (long)(p - args.data()), name_of(p->field) );
>
> I'm writing because I want to put it back as it was, and I don't want
> to work at cross purposes.
>
> This code had problems before the revision, which I'll describe
> shortly.  My objection is that this revision IMO takes the code
> backwards.
>
> 1.  It uses a C-style cast for C++ code in 2025.  C++ invented new cast
> operators for a reason, and cppcheck looks for them.
>
> 2.  The diagnostic framework recognizes %z in gcc 15 (and some versions
> prior).  A bootstrap build should compile the above without the revision.
>
> I think someone is going to tell me that gcc should build on 32-bit Darwin
> without error using the compiler that came with the system. But,
>
>         https://www.gnu.org/software/gcc/gcc-16/criteria.html
>
> makes no such claim.
>
> I would answer:
>
> 3.  The last 32-bit Apple machine was manufactured in 2006, before Taylor
> Swift was famous, when we still knew where Jim Gray was.
>
> 4.  We do not expect any COBOL users on 32-platforms, at all, ever.
>
> 5.  It is counterproductive to restrict new code in gcc to features of
> ancient compilers on obsolete hardware.
>
> 6.  Until and unless we can show the FE works on a 32-bit target,
> adapting the error messages to be correct is pointless.
>
> When I asked about this previously, I was told we distinguish between
> libraries we control and libraries we don't.  Anything relying on the C
> standard library needs to be backwards compatible such that the
> compiler and produced binary use it correctly.  Anything that is part
> of gcc, and thus under our control, we're free to use.  From that I
> concluded that diagnostic messages can use any formatting characters
> supported by the in-tree version of the diagnostic framework.  If that
> is incorrect, I would like to know which version of the diagnostic
> framework to use as a reference, today and in the future.
>
> IOW, what about %z?
>
> What follows is a critique of my own code, in case it informs anything
> above.
>
> The message leaves something to be desired:
>
>         parameter type %zu (%qs)",
> should say
>         parameter #%zu (type %qs)",
>
> The args variable up until recently was a bare C++ array.  To address
> issues rightly (if pedantically) raised by cppcheck, it was converted
> to std::vector.  The above code represents a minimalist change to
> satisfy cppcheck: it passes args.data() into a function and gets back a
> pointer that it uses to derive the index of the offending element.
>
> An improved version of that function will take std::vector as a
> parameter and return N, the index of the offending element in args.
> IMO the returned N should be size_t because basically all indexes are
> size_t these days.  But it could be unsigned long, and gcc_assert could
> enforce that no bits >32 are harmed in formulating the result.
>
> (I bet 1 beer that std::allocator::size_type is size_t for the C++
> standard library Apple shipped with XCode for its last 32-bit system.)
>
> This particular specific example, then, will be resolved some way or
> other.  I'd be interested in hearing how others would approach it, and
> why.
>
> Thank you for helping me understand the %z policy.  I realize my
> message sounds slightly combative.  I only want to express my position
> and assumptions clearly, that there be no confusion.  If there's some
> stated policy I should have been aware of, I would be grateful for the,
> um, pointer.
>
> --jkl
>