Re: [MacPorts] #68543: nmap @7.94 is broken on ppc: MACLookup.cc: error: integer constant is too large for ‘long’ type

[MacPorts]

#68543: nmap @7.94 is broken on ppc: MACLookup.cc: error: integer constant is too
large for ‘long’ type
-------------------------+-------------------------------------------------
  Reporter:              |      Owner:  danielluke
  barracuda156           |
      Type:  defect      |     Status:  closed
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:  2.8.1
Resolution:  wontfix     |   Keywords:  tiger, leopard, snowleopard,
      Port:  nmap        |  powerpc
-------------------------+-------------------------------------------------

Comment (by chrstphrchvz):

 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:
 {{{
 #!diff
 --- MACLookup.cc
 +++ MACLookup.cc
 @@ -157,9 +157,9 @@

      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.

-- 
Ticket URL: <https://trac.macports.org/ticket/68543#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS