[MacPorts] #69433: fdupes @2.3.0_0 does not build on PPC Leopard, Mac OS X 10.5.8, because invalid suffix "b1" on integer constant

[MacPorts]

#69433: fdupes @2.3.0_0 does not build on PPC Leopard, Mac OS X 10.5.8, because
invalid suffix "b1" on integer constant
------------------------+-------------------------
  Reporter:  ballapete  |      Owner:  (none)
      Type:  defect     |     Status:  new
  Priority:  Normal     |  Milestone:
 Component:  ports      |    Version:  2.9.1
Resolution:             |   Keywords:  leopard ppc
      Port:  fdupes     |
------------------------+-------------------------

Comment (by ballapete):

 This error seems to be very strange (at least to me)! In the `pre-
 processed` output I get from `/usr/bin/gcc-4.2 -std=gnu99`:

 {{{
 # 56 "fdupes.c" 2
 # 1 "getrealpath.h" 1
 # 20 "getrealpath.h"
 #define GETREALPATH_H

 #define GETREALPATH_NONE 0b0
 #define GETREALPATH_IGNORE_MISSING_BASENAME 0b1

 char *getrealpath(const char *path, unsigned int options);
 # 57 "fdupes.c" 2
 }}}

 Later `getrealpath()` is used like this on line #1134 (original C source
 -> pre-compiled)

 {{{
 deletepath = getrealpath(dupelist[x]->d_name,
 GETREALPATH_IGNORE_MISSING_BASENAME); -> deletepath =
 getrealpath(dupelist[x]->d_name, 0b1);
 }}}

 and like this on line #1321

 {{{
 deletepath = getrealpath(to_delete->d_name,
 GETREALPATH_IGNORE_MISSING_BASENAME);   -> deletepath =
 getrealpath(to_delete->d_name, 0b1);
 }}}

 Before, on line #285, the same function was this way successfully:
 `fullpath = getrealpath(dir, 0);`.

 So the problem is that `Apple's GCC 4.2` does not understand that "0b1" is
 an `unsingned int`… Which is correct, I think. Assigning a HEX value would
 need writing it as "0xb0" or "0xb1", isn't it?

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