Hi Branden, On Sun, Mar 12, 2023, 18:50 G. Branden Robinson < g.branden.robin...@gmail.com> wrote:
> Hi Bruno, > > I neglected to reply to your suggestions below. > > At 2023-03-06T17:53:55+0100, Bruno Haible wrote: > > > It (and intptr_t) are "optional", apparently. What do you suggest? > > > > They are optional in theory, but all platforms have them. Just include > > <stdint.h> (in C, with help from Gnulib's 'stdint' module for some > > older platforms) or <cstdint> (in C++). > > Good enough for me! I used <stdint.h> because groff's application of > C++ is 30 years old, and has not yet transitioned to the new inclusion > style. (I'd have done so, but I haven't looked up precisely what the > ramifications of that are, and didn't want to fix something that wasn't > operationally broken. Maybe for groff 1.24.) > I'd ask you to not do that. The <c*> headers don't buy you much, and instead adds more divergence from C. BTW, the C++ committee is considering undeprecating the C headers, since realistically they'll need to be supported basically forever. Cheers, Alex > > > uint_fast64_t? > > > > Nah. The *_fast* and *_least* types are only for specific uses, namely > > for micro-optimizing CPU cycles. > > Yes. It seems weird to me that {u,}intptr_t is optional in the standard > when it is precisely what people who _aren't_ micro-optimizing want for > situations like this (taking a pointer value not to dereference it, but > as a unique identifier for an object in memory). > > > > That will blow up on us when IP128 systems start showing up... > > > > I don't see that problem coming. If an architecture has good enough > > 128-bit arithmetic that they use it for all(!) pointers, it will also > > be good enough as a C/C++ integer type. > > :D > > [GNU attributes on MSVC] > > > In looking around the web, I see several competing recommendations > > > for how to preprocess one's way out of the problem. What's your > > > suggestion? > > > > I would just ignore this compiler. Remember that for each platform, > > there needs to be only ONE way to create working binaries. If mingw > > works and MSVC fails due to a buggy compiler, why waste your time with > > that buggy compiler? > > Fair. Also, it's Microsoft's compiler, with which I have never yet > managed to dirty my hands in my mumblety year-long career. > > > I reported the results with this compiler only as an element of the > > big picture. It should not be taken as a suggestion to support that > > compiler. Especially not if it takes a lot of effort. And the DLL > > import/export warnings are a hint that it would be a lot of effort. > > Happily conceded. > > Regards, > Branden >