bug#17773: AIX build errors with coreutils-8.22

[Michael Felt]

So, having looked at the -E output of the compiles I guess it has something
to do with how enum defines it results. And how that gets parsed here:

Goes over my head in any case.

#define _GL_FLOAT_STRLEN_BOUND_L(t, pointlen)                          \
  (1 + _GL_##t##_PREC_BOUND + pointlen + 1                             \
   + _GL_FLOAT_EXPONENT_STRLEN_BOUND (t##_MIN_10_EXP, t##_MAX_10_EXP))
#define  FLT_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( FLT,
pointlen)
#define  DBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L ( DBL,
pointlen)
#define LDBL_STRLEN_BOUND_L(pointlen) _GL_FLOAT_STRLEN_BOUND_L (LDBL,
pointlen)

/* Looser bounds that are locale-independent and are integral constant
   expressions.  */
#define  FLT_STRLEN_BOUND  FLT_STRLEN_BOUND_L (MB_LEN_MAX)
#define  DBL_STRLEN_BOUND  DBL_STRLEN_BOUND_L (MB_LEN_MAX)
#define LDBL_STRLEN_BOUND LDBL_STRLEN_BOUND_L (MB_LEN_MAX)

/* Looser, locale-independent bounds that include the trailing null byte.
*/
#define  FLT_BUFSIZE_BOUND ( FLT_STRLEN_BOUND + 1)
#define  DBL_BUFSIZE_BOUND ( DBL_STRLEN_BOUND + 1)
#define LDBL_BUFSIZE_BOUND (LDBL_STRLEN_BOUND + 1)

#endif /* _GL_FTOASTR_H */

Then in od.c we have this:
#define PRINT_FLOATTYPE(N, T, FTOASTR, BUFSIZE)                         \
  PRINT_FIELDS (N, T, fmt_string _GL_UNUSED,                      \
                char buf[BUFSIZE];                                      \
                FTOASTR (buf, sizeof buf, 0, 0, x);                     \
                xprintf ("%*s", adjusted_width, buf))

PRINT_TYPE (print_s_char, signed char)
PRINT_TYPE (print_char, unsigned char)
PRINT_TYPE (print_s_short, short int)
PRINT_TYPE (print_short, unsigned short int)
PRINT_TYPE (print_int, unsigned int)
PRINT_TYPE (print_long, unsigned long int)
PRINT_TYPE (print_long_long, unsigned_long_long_int)

PRINT_FLOATTYPE (print_float, float, ftoastr, FLT_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_double, double, dtoastr, DBL_BUFSIZE_BOUND)
PRINT_FLOATTYPE (print_long_double, long double, ldtoastr,
LDBL_BUFSIZE_BOUND)

which in od.i becomes (only the first PRINT_FLOATTYPE output), for
readability.

static void print_float (size_t fields, size_t blank, void const *block,
char const *fmt_string, int width, int pad) { float const *p = block;
uintmax_t i;
 int pad_remaining = pad; for (i = fields; blank < i; i--) { int next_pad =
pad * (i - 1) / fields; int adjusted_width = pad_remaining - next_pad +
width;
float x = *p++; char buf[( (1 + _GL_FLT_PREC_BOUND + 4 + 1 + ( -100 < (-37)
&& (38) < 100 ? 3 : -1000 < (-37) && (38) < 1000 ? 4 : -10000 < (-37) &&
(38) <
 10000 ? 5 : -100000 < (-37) && (38) < 100000 ? 6 : -1000000 < (-37) &&
(38) < 1000000 ? 7 : ((((sizeof (int) * (8) - (! ((__typeof__ (int)) 0 <
(__typeof_
_ (int)) -1))) * 146 + 484) / 485) + (! ((__typeof__ (int)) 0 < (__typeof__
(int)) -1))) )) + 1)]; ftoastr (buf, sizeof buf, 0, 0, x); xprintf ("%*s",
adju
sted_width, buf); pad_remaining = next_pad; } }

Aren't macros fun!

Anyway, if this is the "workings" of the bug, then maybe I can get it
submitted for a bugfix.

So, before I do any try and submit a bugreport to IBM - please verify that
the above is "the bug" - perhaps showing how your compiler completes the
"od.i" code.

Michael


On Wed, Jun 18, 2014 at 9:16 PM, Michael Felt <address@hidden> wrote:

> I am confused by what is in git regarding ftoastr.h
>
> The enum code has been around "forever" and not caused a problem. I think
> the problem lies elsewhere because version 8.20 builds fine.
>
> address@hidden:[/data/prj/gnu/coreutils]diff ./coreutils-8.22/lib/ftoastr.h
> ./coreutils-8.15/lib/ftoastr.h
> 3c3
> <    Copyright (C) 2010-2013 Free Software Foundation, Inc.
> ---
> >    Copyright (C) 2010-2012 Free Software Foundation, Inc.
>
> So, I do not understand the why the change to ftoastr.h is being
> considered. The motivation that AIX compiler "has a bug" seems misleading
> as this identifer has worked well for ftoast.c for many years.
> The simple "include" of ftoastr.h to src/od.c and src/getlimits.c seems to
> be making assumptions that ftoastr.c has not. So, maybe there is another
> more elegant solution?
>
>
> On Wed, Jun 18, 2014 at 8:59 PM, Michael Felt <address@hidden> wrote:
>
>> Curious why you are calling this a compiler bug. I am not a POSIX nerd,
>> but it looks as if the old code was compiler independent, and now it is
>> dependent on something.
>>
>> Just one difference in od.c that shows a change in identifer conventions.
>>
>> What is the origin of the _GL_* identifiers? "Unix" or "Not Unix"?
>>
>> from diff -u ./coreutils-8.20/src/od.c ./coreutils-8.22/src/od.c
>>
>> @@ -1050,8 +1056,8 @@
>>  }
>>
>>  static void
>> -format_address_none (uintmax_t address ATTRIBUTE_UNUSED,
>> -                     char c ATTRIBUTE_UNUSED)
>> +format_address_none (uintmax_t address _GL_UNUSED,
>> +                     char c _GL_UNUSED)
>>  {
>>  }
>>
>> I also note that the identifiers involved go back to at least coreutils
>> 8.9 in ./lib/ftoastr.h
>>
>> So, this has been known, and managed, for a long time.
>>
>> It is your code, so you can call it a bug if you wish - I am thinking,
>> for now, that it is a dependency on something not found by default when
>> using the xlc compilers. But I may be wrong :address@hidden
>>
>>
>> On Fri, Jun 13, 2014 at 5:37 PM, Pádraig Brady <address@hidden> wrote:
>>
>>> On 06/13/2014 02:38 PM, Michael Felt wrote:
>>>
>>> > make[2]: Entering directory `/data/prj/gnu/coreutils/coreutils-8.22'
>>> >   CC       src/od.o
>>> > "src/od.c", line 432.47: 1506-045 (S) Undeclared identifier
>>> > _GL_FLT_PREC_BOUND.
>>>
>>> >   CC       src/getlimits.o
>>>
>>> > "src/getlimits.c", line 112.53: 1506-045 (S) Undeclared identifier
>>> > _GL_LDBL_PREC_BOUND.
>>>
>>>
>>> I think Paul has already avoided this AIX compiler bug,
>>> and so this will be fixed in the upcoming coreutils-8.23
>>> http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=6f053ff1
>>>
>>> thanks,
>>> Pádraig.
>>>
>>
>>
>