On Thu, 31 Jul 2025, 22:44 Jonathan Wakely, <jwakely....@gmail.com> wrote:
> > > 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 > 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 >> >
