nmap @7.94 is broken on ppc: MACLookup.cc: error: integer constant is too large for ‘long’ type

[barracuda156]

:info:build libtool: compile:  /usr/bin/gcc-4.2 -DHAVE_CONFIG_H -I. -I../include -I../include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -c tun-none.c -o tun-none.o
:info:build /usr/bin/g++-4.2 -c -I../liblua -I../libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I../nbase -I../nsock/include -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing PacketElement.cc -o PacketElement.o
:info:build /usr/bin/gcc-4.2 -O2 -Wall -Wextra -DLUA_COMPAT_5_3  -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall   -DLUA_USE_MACOSX   -c -o lobject.o lobject.c
:info:build /bin/sh ../libtool --tag=CC   --mode=link /usr/bin/gcc-4.2  -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -version-info 1:1:0 -L/opt/local/libexec/openssl3/lib -L/opt/local/lib -Wl,-headerpad_max_install_names -arch ppc -o libdnet.la -rpath /opt/local/lib addr-util.lo addr.lo blob.lo ip-util.lo ip6.lo rand.lo arp-bsd.lo eth-bsd.lo fw-none.lo intf.lo ip.lo route-bsd.lo tun-none.lo 
:info:build /usr/bin/g++-4.2 -c -I../liblua -I../libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I../nbase -I../nsock/include -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing NetworkLayerElement.cc -o NetworkLayerElement.o
:info:build /usr/bin/g++-4.2 -c -I../liblua -I../libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I../nbase -I../nsock/include -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing TransportLayerElement.cc -o TransportLayerElement.o
:info:build /usr/bin/g++-4.2 -c -I./liblua -I./libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I./nbase -I./nsock/include -DHAVE_CONFIG_H -DNMAP_PLATFORM=\"powerpc-apple-darwin10.0.0d2\" -DNMAPDATADIR=\"/opt/local/share/nmap\" -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing   MACLookup.cc -o MACLookup.o
:info:build /usr/bin/gcc-4.2 -O2 -Wall -Wextra -DLUA_COMPAT_5_3  -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall   -DLUA_USE_MACOSX   -c -o lopcodes.o lopcodes.c
:info:build /usr/bin/gcc-4.2 -O2 -Wall -Wextra -DLUA_COMPAT_5_3  -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall   -DLUA_USE_MACOSX  -c lparser.c
:info:build MACLookup.cc:161: error: integer constant is too large for ‘long’ type
:info:build /usr/bin/g++-4.2 -c -I../liblua -I../libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I../nbase -I../nsock/include -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing ARPHeader.cc -o ARPHeader.o
:info:build /usr/bin/g++-4.2 -c -I./liblua -I./libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I./nbase -I./nsock/include -DHAVE_CONFIG_H -DNMAP_PLATFORM=\"powerpc-apple-darwin10.0.0d2\" -DNMAPDATADIR=\"/opt/local/share/nmap\" -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing   nmap_dns.cc -o nmap_dns.o
:info:build MACLookup.cc: In function ‘void mac_prefix_init()’:
:info:build MACLookup.cc:161: warning: format ‘%0*lX’ expects type ‘long unsigned int’, but argument 3 has type ‘long long unsigned int’
:info:build libtool: link: ar cru .libs/libdnet.a  addr-util.o addr.o blob.o ip-util.o ip6.o rand.o arp-bsd.o eth-bsd.o fw-none.o intf.o ip.o route-bsd.o tun-none.o
:info:build /usr/bin/g++-4.2 -c -I../liblua -I../libdnet-stripped/include -I/opt/local/libexec/openssl3/include -isystem/opt/local/include -I/opt/local/libexec/openssl3/include -I../nbase -I../nsock/include -DHAVE_CONFIG_H -D_FORTIFY_SOURCE=2 -no-cpp-precomp -pipe -I/opt/local/libexec/openssl3/include -Os -arch ppc -Wall -fno-strict-aliasing EthernetHeader.cc -o EthernetHeader.o
:info:build libtool: link: ranlib .libs/libdnet.a
:info:build make: *** [MACLookup.o] Error 1

Cannot test on i386, but possibly broken there too. Earlier versions installed fine, AFAICT.

[barracuda156]

Same error on 10.5.8

[danielluke (Daniel J. Luke)]

I don’t have an old machine to test on - so this is going to require work from someone who uses the port on a ppc machine. It might also be worthwhile to report it upstream as it’s not actually a problem with the MacPorts build (but if upstream doesn’t want to support such an old OS we can still add a patch to macports once someone develops it.

[danielluke (Daniel J. Luke)]

I'm going to close this for now - if anyone wants to work on it, feel free to reopen.

[chrstphrchvz (Christopher Chavez)]

nmap still claimed to support 32-bit platforms as of release 7.92 (2021-08-07). So the use of %0*lX looks like an upstream issue; I would think that causes the highest digit to not be printed correctly when long is 32-bit. It also causes a warning even on 64-bit with modern compilers (e.g. LLVM.org clang 17.0.3):

MACLookup.cc:161:93: warning: format specifies type 'unsigned long' but the argument has type 'u64' (aka 'unsigned long long') [-Wformat]
  161 |       error("MAC prefix %0*lX is duplicated in %s; ignoring duplicates.", (int)(pfx >> 36), pfx & 0xfffffffffL, filename);
      |                         ~~~~~                                                               ^~~~~~~~~~~~~~~~~~
      |                         %0*llX

Since pfx has type u64 a.k.a. uint64_t, I think the correct approach is this:

MACLookup.cc

@@ -157 +157 @@
 
     std::pair<MacMap::iterator, bool> status = MacTable.insert(std::pair<u64, const char *>(pfx, string_pool_substr(vendor, endptr)));
 
     if (!status.second && o.debugging > 1)
-      error("MAC prefix %0*lX is duplicated in %s; ignoring duplicates.", (int)(pfx >> 36), pfx & 0xfffffffffL, filename);
+      error("MAC prefix %0*" PRIX64 " is duplicated in %s; ignoring duplicates.", (int)(pfx >> 36), pfx & 0xfffffffffL, filename);
   }
 
   fclose(fp);
   return;

Regarding the use of 0xfffffffffL, that is fine under C++11. nmap seems to assume C++11 support, given its use of e.g. long long and uint64_t—features which earlier compilers might only have as an extension. A workaround for GCC < 4.3 is to use 0xfffffffffLL instead, but since that amounts to a cosmetic change under C++11, it is not necessarily something upstream would be interested in, unless e.g. they find it stylistically preferable.

[barracuda156]

Replying to danielluke:

I'm going to close this for now - if anyone wants to work on it, feel free to reopen.

Well, please reopen. You may remove assignment, of course, but this is a genuine bug which has to be fixed.

[barracuda156]

Replying to chrstphrchvz:

Regarding the use of 0xfffffffffL, that is fine under C++11. nmap seems to assume C++11 support, given its use of e.g. long long and uint64_t—features which earlier compilers might only have as an extension. A workaround for GCC < 4.3 is to use 0xfffffffffLL instead, but since that amounts to a cosmetic change under C++11, it is not necessarily something upstream would be interested in, unless e.g. they find it stylistically preferable.

We can set cxx_standard to 2011, I do not see any reasons preventing that.

[danielluke (Daniel J. Luke)]

Replying to barracuda156:

Well, please reopen. You may remove assignment, of course, but this is a genuine bug which has to be fixed.

Are you volunteering to fix this?

again, I'm happy to apply a patch if someone who is experiencing the problem can develop and test it - and I'd also recommend addressing it upstream as it's not a problem specific to the macports build.

[chrstphrchvz (Christopher Chavez)]

Fixes proposed in ​https://github.com/macports/macports-ports/pull/21148

I have submitted the format string bugfix upstream: ​https://github.com/nmap/nmap/pull/2732
This issue does not cause a crash as long as the nmap-mac-prefixes file contains no duplicates.

[danielluke (Daniel J. Luke)]

It would be nice if someone with a ppc machine can verify that this patch fixes things for them as well.

[barracuda156]

Replying to danielluke:

It would be nice if someone with a ppc machine can verify that this patch fixes things for them as well.

Sure, I can do that in a few min.

UPD. There is one more fix required: ​https://github.com/macports/macports-ports/pull/21148#issuecomment-1786381645 After that it builds fine.

[chrstphrchvz (Christopher Chavez)]

In 03ae697a224ebe6b82ffbb1bf8cabd440adf218b/macports-ports (master):

nmap: fixes for 32-bit and pre-C++11 platforms

Fixes: #68543

Co-authored-by: Sergey Fedorov <vital.had@…>

[danielluke (Daniel J. Luke)]

Just to also note here - this was merged /before/ maintainer approval. Please refrain from doing so for non-openmaintainer ports in the future.