acceptable diagnostic format characters

[Jonathan Wakely]

On Thu, 31 Jul 2025, 22:44 Jonathan Wakely, <jwakely.gcc@gmail.com> wrote:

>
>
> 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
>

You could cast the argument to size_t to make it correct, or cast it to
some other known type such as long, and then use the corresponding
specifier such was %ld, which seems to be what the change did.


>
>
> +            "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.
>
>
Meh. The cast is fine imho


>>
>> 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.
>
>
But the "index" is actually just a pointer subtraction, so the type is
ptrdiff_t



>>
>> 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
>>
>