hint for ticket:2479788

diff --git a/TODO b/TODO
index 32e6005d0345b0d1ebf078e354f3d7597e1485cc..ab30ddcc0378fe7a92c4bc5ab2ee868323135c6d 100644 (file)
--- a/TODO
+++ b/TODO
@@ -4,6 +4,11 @@ SHORTTERM
 - most is multithreaded ... but zzip_dir_open (Thorsten Schöning)
 - rboerdijk@ does also report errors on overlapping reads, another
    one pointed to the usage of seek_set that may cause the problems
+- extend aligned-access check in the autoconf macro such that it can
+  cover the cross-compiling case - libpcap AC_LBL_UNALIGNED_ACCESS
+  uses         alpha*|arm*|bfin*|hp*|mips*|sh*|sparc*|ia64|nv1)
+                ac_cv_lbl_unaligned_fail=yes
+  for that.
 
 WISHLIST
 
@@ -21,7 +26,7 @@ WISHLIST
 - Sligthly More documentation. With the generation of man pages and
   multiple pages for the website, it does already look acceptable.
   It should still get better of course - kinda newbie friendly *g*
-  
+
 - Boris Schäling likes to open a zzip archive in memory.
 
 KNOWN PROBLEMS
@@ -29,7 +34,7 @@ KNOWN PROBLEMS
 The win32 compilers need each a different config.h derivate that
 matches both the headers shipped with the compiler and installed
 with updates of the SDK. There is no autoconfigure on win32 as
-that - unless you install some unix tools along. 
+that - unless you install some unix tools along.
 
 The sparc-sun-solaris2.* will utter warnings for "char subscript"
 which is caused by isdigit() from ctype.h - this will NOT FIX as
@@ -37,14 +42,14 @@ it is only in the example source code and we want to keep those
 lean and mean to make them easy to adopt by developers.
 
 The hppa1.1-hp-hpux10.20 did show spurious problems of making
-shared libraries - this may well fix with an update of the 
+shared libraries - this may well fix with an update of the
 libtool package, the libtool 1.4 is dated 2001/04/24
 
 There are reports of misaligned access to some zip fields that
-I would guess to be on little-endian non-x86 platforms. The current 
+I would guess to be on little-endian non-x86 platforms. The current
 bytewise access of multibyte fields is targetted towards the
-bigendian unix machines. The fix would need to go to fetch.h but 
-so far no response came about as that one could test a solution. 
+bigendian unix machines. The fix would need to go to fetch.h but
+so far no response came about as that one could test a solution.
 
 There are spurious reports of users on win32 platforms that tell
 of some problems with a specific zip file they have but it was
@@ -55,9 +60,9 @@ Please send all those zip files to the maintainer, perhaps it
 can help to find the real cause (I doubt it is in zziplib, but..)
 
 Since lately the xml docbook tools have hardened the checks on the
-input xml that is used for manpage generation. Interestingly the 
-resulting manpages are still okay but one should try to fixaway the 
-warnings as may be later the result would lead to garbage output 
+input xml that is used for manpage generation. Interestingly the
+resulting manpages are still okay but one should try to fixaway the
+warnings as may be later the result would lead to garbage output
 due more changes in the tools. Needs to change the xml generator
 used in zzip (a python script).