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.
signature.asc
Description: Digital signature
