Francesco P. Lovergine <fran...@debian.org> (2014-03-26):
> While I accepted the patch a few minutes ago, indeed I seriously now doubt 
> that
> the fix is correct.
> 
> It seems to me that in the original program the LITTLE_ENDIAN should be
> intended as a static build-time definition for the host where the program is 
> built.
> 
> So the NAN definition should be intended instead as nan(). That's because
> the shapefile format is endianess-independent and shapelib reads/writes 
> fields on the
> basis of the host platform to respect the format. So the NAN should be
> intended as the *host* NaN format, indeed (to be translated in the shp format 
> NaN, i.e. little endian). 
> That poses a problem on the pcc architecture for instance: __nan_bytes will 
> be not the 
> correct NaN value and will result as a big endian in the file.
> 
> See http://dl.maptools.org/dl/shapelib/shapefile.pdf for format.
> 
> Do you agree?

To be frank I didn't quite get why it was considered a good idea to
hardcode setting -Dfoo in contrib/Makefile unconditionally instead of
looking at the relevant arch-specific bits. So I assumed this was
deliberate and that this setting was orthogonal to what's in system
headers, that's why I proposed the patch you saw.

(From a quick look between last two upstream releases, this part didn't
change; I guess this issue popped up due to updated system headers, but
I didn't look into it to see what exactly triggered it.)

I guess looking at __BYTE_ORDER would be a better way to actually check
a system's endianness, #error-ing if it's neither __LITTLE_ENDIAN or
__BIG_ENDIAN; I have no idea how much that is portable, but upstream
should probably now a bit about msvc and advise whether that's a viable
option.

Mraw,
KiBi.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Pkg-grass-devel mailing list
Pkg-grass-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-grass-devel

Reply via email to