RE: Error in libfetish.a

[John D. Ballentine III]

Bob - 

OK, I ran the command you gave me and got the following result:

adjust_value (int inexact_style, long double value)
{


  if (inexact_style != human_round_to_nearest && value <    4294967295u l
)
    {
      uintmax_t u = value;
      value = u + (inexact_style == human_ceiling && u != value);
    }

  return value;
}

...followed by a lot of other stuff, but I think this is what you wanted.

Actually, I'm not certain which software I have on this system.  I just
started in this position a bit more than a year ago, so I'm not sure how
complete some of the packages are...  I do have the ANSI C compiler
installed, though.  Is there something I should be specifying to force the
install to use that package instead of gcc?

Similarly, since it is a development machine, I'll probably just keep the
GNU make in my directory, as the REAL programmers around here probably
wouldn't appreciate me messing them up. :)

(Just ask anyone around here - I'm enough of a character as it is...)


Paul - 

I see the following values:
#define HAVE_INTTYPES_H 1
/* #undef HAVE_STDINT_H */
/* #undef uintmax_t */

>From inttypes.h:

>grep -i uintmax_t inttypes.h
** intmax_t and uintmax_t are to be the largest signed and unsigned integer
/* The following macros define I/O formats for intmax_t and uintmax_t.
extern uintmax_t __strtoull (const char *, char**, int);
extern uintmax_t __wcstoull(const wchar_t *, wchar_t **, int);
extern uintmax_t __strtoull ();
extern uintmax_t __wcstoull();
#define strtoumax(__a, __b, __c) (uintmax_t)strtoul(__a, __b, __c)
#define wcstoumax(__a, __b, __c) (uintmax_t)wcstoul(__a, __b, __c)

And:
> grep UINTMAX_MAX inttypes.h
** and UINTMAX_MAX (maximum value of the largest supported unsigned integer
#define UINTMAX_MAX UINT64_MAX
#define UINTMAX_MAX UINT32_MAX

I didn't find a stdint.h... Which seems wrong, somehow. :)

Usually I look for the last stable release, but since I am having so much
fun with this I went ahead and grabbed the alpha release you pointed to.
Result:


        gcc -DHAVE_CONFIG_H -DLIBDIR=\"/usr/local/lib\" -I. -I. -I..  -I..
-I.
  -g -O2 -c human.c
human.c: In function `adjust_value':
human.c:77: parse error before `l'
human.c:80: `u' undeclared (first use this function)
human.c:80: (Each undeclared identifier is reported only once
human.c:80: for each function it appears in.)
human.c: At top level:
human.c:83: parse error before `return'
*** Error exit code 1

Stop.

Oh well...


-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Monday, February 02, 2004 10:36 PM
To: John D. Ballentine III
Cc: 'address@hidden'
Subject: Re: Error in libfetish.a


> package) and got the following error:
> 
> gcc -DLIBDIR=\"/usr/local/lib\" -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.
-g
> -O2
> -c `test -f 'human.c' || echo './'`human.c
> human.c: In function `adjust_value':
> human.c:111: parse error before `l'
> human.c:114: `u' undeclared (first use this function)
> human.c:114: (Each undeclared identifier is reported only once
> human.c:114: for each function it appears in.)
> human.c: At top level:
> human.c:117: parse error before `return'
> make[3]: *** [human.o] Error 1

Here is the code for this error.

104 static long double
105 adjust_value (int inexact_style, long double value)
106 {
107   /* Do not use the floorl or ceill functions, as that would mean
108      checking for their presence and possibly linking with the
109      standard math library, which is a porting pain.  So leave the
110      value alone if it is too large to easily round.  */
111   if (inexact_style != human_round_to_nearest && value < UINTMAX_MAX)
112     {
113       uintmax_t u = value;
114       value = u + (inexact_style == human_ceiling && u != value);
115     }
116 
117   return value;
118 }

Parse error before 'l' on 111 looks like UINTMAX_MAX is not being
understood properly.  But the 'u' undeclared could mean that uintmax_t
is not known.  Either way something is not happy there.

On my HP-UX 10.20 system this has a complex set of macros which I
won't reproduce here.  But you can use -E to process the file with gcc
and have it show you the result.

  gcc -E -DHAVE_CONFIG_H -I. -I.. human.c | less +/^adjust_value

What does that show on the screen for you?  For me I see the
following, and a lot more blank lines where the comments were which I
squeezed out.

  static long double
  adjust_value (int inexact_style, long double value)
  {
    if (inexact_style != human_round_to_nearest && value <
18446744073709551615ull )
      {
        uintmax_t u = value;
        value = u + (inexact_style == human_ceiling && u != value);
      }

    return value;
  }

What does that show for you in the UINTMAX_MAX position, that
18446744073709551615ull in my output above?  It would seem that your
installation of gcc does not understand 'ull'.  Have you used gcc on
your system for many programs?  At this point I am thinking that is
your problem.  I don't think gcc is all there.  I mostly use the HP
ANSI C compiler.  But I also have gcc-2.95.2 and it compiles
coreutils-5.0 on HP-UX 10.20 fine.

Do you have the native HP ANSI C compiler?  (This is not the same as
the bundled "crippled" compiler.  The ANSI compiler is extra.)  If so
then it would compile this fine.  Just not wanting to overlook this
possibility.