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

[Alejandro Colomar (man-pages)]

Hi Branden,

On Sun, Mar 12, 2023, 18:50 G. Branden Robinson <
g.branden.robinson@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
>