Re: [platform-testers] groff 1.23.0.rc3 on native Windows

[G. Branden Robinson]

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

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

signature.asc
Description: PGP signature