Re: Some misprints and problems

[Ethan A M. <merritt@u.washington.edu>]

On Wednesday 10 September 2008, you wrote:
> > | I have now fixed these in CVS by adding tests in configure.in
> > | Cropping will fail silently for platforms that both
> > | - do not use autoconf
> > | - have (sizeof(int) != 4)
> > | This can be fixed by adding an explicit definition of GP_UINT32_T
> > | in the appropriate platform-specific configuration file.

> I know it's a bit late, but I'll let you know that cairo-based terminals 
> depend on pango, which in turns depends on GLib, which defines integer 
> types whose sizes are guaranteed on all platforms : gint8, guint8, 
> gint16, guint16, gint32, guint32, gint64, guint64. You can use them by 
> including glib.h first, and then there's no more autoconf magic needed.

uint32_t is defined in the C99 standard, but not for C++.
The u_int32_t type is used by BSD and is defined in various compatibility
headers.  But neither of these is guaranteed to be on all platforms.
We explicitly try not to depend on C99 compliance, and
also I do not think we can depend on GLib being present. 

> Besides, I've been using the same kind of byte-wise and 32-bits 
> manipulation with a simple "unsigned int" in 
> gp_cairo.c:gp_cairo_draw_image(), where "unsigned int" is implicitly 32 
> bits. 

I think that is not safe.
Has the code been tested on native 64-bit machines?
That is, machines where sizeof(int)==8 ?
I don't currently have such a machine in the lab, but they are not so 
very rare.  I used to have several.

> If you choose to be bullet-proof with this crop code, I guess it's  
> worth changing the image code too !

Yes.  If you look in datafile.c, you'll see that there is a ridiculous
amount of code and pre-checking just devoted to sorting out the size of
possible data units.  I wish this could all go away, or be sorted out
by autoconf, but so far that's what we've got.

> On a side note, I am inclined to say that it would have been better to 
> fix the code that makes margins too big instead of cropping the picture 
> later...

Well, I'm already on record as disliking the crop option.
But if we're going to have it at all, we should at least try to make
it compile+work on all platforms.


-- 
Ethan A Merritt