On Thu, 31 Jul 2025, 22:23 James K. Lowden, <jklow...@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 >
