[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