[GRASS5] compilation HP-UX
Eric G. Miller
egm2 at jps.net
Wed Jun 13 21:37:02 EDT 2001
On Thu, Jun 14, 2001 at 12:39:15AM +0100, Glynn Clements wrote:
>
> Robert Lagacé wrote:
>
> > uint8_t and uint32_t are defined in /usr/include/sys/_inttypes.h where they
> > are defined under __INTTYPES_INCLUDED the following way
> >
> > typedef unsigned char uint8_t; /* 8-bit unsigned integer */
> > typedef unsigned int uint32_t; /* 32-bit unsigned integer */
> >
> > So as uint32_t should be defined typedef unsigned int uint32_t as suggested.
> >
> > I do not know by which include file _inttypes.h is pick up.
> >
> > This solution may work on other systems.
>
> ISO C 9x[1] specifies <stdint.h> for these types. It does state that
> "These types need not exist in an implementation", although that's
> probably to allow for implementations which don't have any type which
> could be used for [u]int64_t.
>
> [1] This is from the 1998-08-03 draft (section 7.18.1.1).
I probably should've never messed with the can of worms. Unfortunately,
these data types can exist in all manner of places on different systems
and with conflicting definitions... I search for some ./configure hacks
to deal with it, but never implemented them since d.area is still
fundamentally broken.
Note: I'm trying to put a replacement together for d.area (actually, I
have one already but the license for some borrowed code is too
restrictive). Also, d.area is only a drawing routine. I don't know
where that bit about reporting area/perimeter info comes from, but it
was never in the code when I started hacking on it.
If you'd like to try a d.area for "non-commercial use only" (the bad
license restriction) I can send or make available a tarball (no uint8_t
type involved!).
--
Eric G. Miller <egm2 at jps.net>
More information about the grass-dev
mailing list