Don't do attempt unaligned memory access on machine that can't do that

git-svn-id: http://svn.code.sf.net/p/netpbm/code/trunk@2809 9d0c8265-081b-0410-96cb-a4ca84ce46f8

3 files changed, 14 insertions, 10 deletions

diff --git a/converter/other/giftopnm.c b/converter/other/giftopnm.c
index 2e6ae1d9..76cf4bff 100644
--- a/converter/other/giftopnm.c
+++ b/converter/other/giftopnm.c
@@ -24,6 +24,7 @@
 #include <string.h>
 #include <assert.h>
 
+#include "pm_config.h"
 #include "pm_c_util.h"
 #include "mallocvar.h"
 #include "nstring.h"
@@ -39,12 +40,6 @@
 
 #define MAX_LZW_BITS  12
 
-#if !defined(BYTE_ORDER) || !defined(LITTLE_ENDIAN)
-  /* make sure (BYTE_ORDER == LITTLE_ENDIAN) is FALSE */ 
-  #define BYTE_ORDER    0
-  #define LITTLE_ENDIAN 1
-#endif
-
 #ifndef   FASTPBMRENDER
   #define FASTPBMRENDER TRUE
 #endif
@@ -684,7 +679,7 @@ bitsOfLeBuffer(const unsigned char * const buf,
 
     assert(len <= 16);
 
-    if (BYTE_ORDER == LITTLE_ENDIAN)
+    if (BYTE_ORDER == LITTLE_ENDIAN && UNALIGNED_OK)
         /* Fast path */
         codeBlock = *(uint32_t *) & buf[start/8];
     else
diff --git a/doc/HISTORY b/doc/HISTORY
index 1bf3a1ee..9bd8599c 100644
--- a/doc/HISTORY
+++ b/doc/HISTORY
@@ -6,6 +6,10 @@ CHANGE HISTORY
 
 not yet  BJH  Release 10.76.00
 
+              giftopnm: Fix bug: crash on little-ending computers that can't
+              toleration unaligned memory access.  Thanks Ignatios Souvatzis
+              (is@netbsd.org).  Broken in Netpbm 10.47 (June 2009).
+
               cmuwmtopbm: fix trivial memory leak.  Always broken (cmuwmtopbm
               was in primordial Pbmplus, in 1988).
 
diff --git a/pm_config.in.h b/pm_config.in.h
index 72cb477e..d156127e 100644
--- a/pm_config.in.h
+++ b/pm_config.in.h
@@ -257,12 +257,17 @@
 /* UNALIGNED_OK means it's OK to do unaligned memory access, e.g.
    loading an 8-byte word from an address that is not a multiple of 8.
    On some systems, such an access causes a trap and a signal.
+
+   This determination is conservative - There may be cases where unaligned
+   access is OK and we say here it isn't.
+
+   We know unaligned access is _not_ OK on at least SPARC and some ARM.
 */
 
-#if defined(__sparc__)
-# define UNALIGNED_OK 0
-#else
+#if defined(__x86_64__) | defined(__i486__) | defined(__vax__)
 # define UNALIGNED_OK 1
+#else
+# define UNALIGNED_OK 0
 #endif