Bug in image code ?

[V. <gae...@no...>]

    I have found a strange behaviour of the image code.=20
    Here is a minimal example :

set xrange [-10:137]
set yrange [-10:157]

unset colorbox
plot 'blutux.rgb' binary array=3D128x128 flip xy \
format=3D'%uchar%uchar%uchar' every 64:16 using ($1+$2+$3) with image


With the standard terminal drivers (x11, post, png) this works without a
flaw, but while working on the povray terminal, on the image code, I note=
d
that corner[0].x ends up being negative ! But it is a unsigned int !!
The other terminals use it by calling it "(int) corner[0].x", thus
forcing the conversion to a negativ integer. However if I put a=20
"fprintf(gpoutfile, "corner[0].x : %u\n",corner[0].x)" I get a
ridiculously high value printed. Printing it as an integer solves the
problem, and this is how I worked around this.
    I suspect this problem is lying around in other places (I think I
might have seen it elsewhere, but it is hard to trick gnuplot into
making a negative value for a coordinate). Maybe those "(int)" casts in
many of the terminal drivers are just hiding more bug.
    I just had a look at the way the post terminal calls this :
line 3777 : fprintf(gppsfile, "%d %d translate\n", corner[0].x, corner[0]=
.y);

    Why %d and not %u ?

	I am wrong or is there a problem here ? Maybe these should not
be unsigned ints, but ints ? Checking for there sign seems a bit
complicated.

--
    Ga=EBl