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) );
+ "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
