CVS-19981209: Patch for "unsigned HOST_WIDE_INT" on Solaris2.6

Jeffrey A Law law@cygnus.com
Fri Dec 11 02:10:00 GMT 1998


  In message < 13935.39643.570262.15767@sls5gj.stgl.sel.alcatel.de >you write:
  > #ifndef HOST_WIDE_INT
  > # if HAVE_INTTYPES_H
  > #  include <inttypes.h>
  > #  define HOST_WIDE_INT intmax_t
  > # else
  > 
  > The system's <inttypes.h> then defines a
  > 
  > typedef int64_t intmax_t;
  > 
  > This is, what gcc is moaning about:
  > 
  >   register unsigned HOST_WIDE_INT i;
  > 
  > which becomes after pre-processing:
  > 
  >   register unsigned intmax_t i;
  > 
  > which is simply not allowed.
  > 
  > As Dave Brolley suggested in a different email, we should get rid of
  > the #if HAVE_INTTYPES_H stuff and use the plain old #define way
  > instead. I've extended this to avoid defining HOST_WIDE_INT redundantly
  > in several files (cpplib.h, machmode.h, probably others), but to provide
  > only *one* definition in e.g. "system.h".  If we agree on that, I'll
  > send a new patch.
So does anyone know why we've bothered with inttypes.h to start with?

I agree, it seems rather silly to have two different ways to get
HOST_WIDE_INT defined, and as a result of the differences, code which
works in one context fails in another context (as we've seed for the
"unsigned HOST_WIDE_INT" case).

Paul -- do you remember the original motivation behind adding uses of
inttypes.h?

jeff




More information about the Gcc-patches mailing list