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

[Bruno Haible]

G. Branden Robinson wrote:
> > * With mingw (in 64-bit mode), the build failed here:
> > 
> > ../src/include/symbol.h: In member function ‘long unsigned int 
> > symbol::hash() const’:
> > ../src/include/symbol.h:61:25: error: cast from ‘const char*’ to ‘long 
> > unsigned int’ loses precision [-fpermissive]
> >    return (unsigned long)s;
> > 
> > The integral type that is as wide as a pointer is 'uintptr_t' (from
> > <inttypes.h> or <stdint.h>), not 'unsigned long'.
> 
> Right.  You found an attempt at a value-preserving type cast from groff
> 1.07, in 1993.  :)
> 
> It looks like I cannot assume the existence of a uintptr_t type on C++
> systems?
> 
> https://en.cppreference.com/w/cpp/types/integer
> 
> 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++).

> uint_fast64_t?

Nah. The *_fast* and *_least* types are only for specific uses, namely
for micro-optimizing CPU cycles.

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


> > * With MSVC, there was an internal compiler error.
> 
> C:\cygwin64\home\bruno\groff-1.23.0.rc3\src\libs\libgroff\getopt.c(251): 
> error C2143: syntax error: missing ')' before '('
> C:\cygwin64\home\bruno\groff-1.23.0.rc3\src\libs\libgroff\getopt.c(251): 
> error C2091: function returns function
> C:\cygwin64\home\bruno\groff-1.23.0.rc3\src\libs\libgroff\getopt.c(251): 
> error C2059: syntax error: ')'
> C:\cygwin64\home\bruno\groff-1.23.0.rc3\src\libs\libgroff\getopt.c(251): 
> error C2143: syntax error: missing ')' before 'type'
> C:\cygwin64\home\bruno\groff-1.23.0.rc3\src\libs\libgroff\getopt.c(251): 
> error C2085: 'argc': not in formal parameter list
> ...
> 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?

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.

Bruno