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
