source/libs/zziplib/zziplib-0.13.62/TODO

   1 SHORTTERM
   2 - handle international filenames more gracefully (unicode API?)
   3 - most is multithreaded ... but zzip_dir_open (Thorsten Schöning)
   4 - rboerdijk@ does also report errors on overlapping reads, another
   5    one pointed to the usage of seek_set that may cause the problems
   6 - ubuntu packager added man.1 for the zz*-binaries, could be upstream.
   7
   8
   9
  10
  11 WISHLIST
  12
  13 - Check the CRC value at the end of read... and add more error codes.
  14
  15 - Do more test. Currently use only with tested "friendly" archives.
  16   This is also related to usages of zziplib in virus detection
  17   code which should better have a hardened library code. That does
  18   also include inflate interface code to need the most testing.
  19
  20 - the buffer reusage code was not strictly multithreading. It should
  21   be fixed by now but it would be better to have an automatic test
  22   routine to check reentrancy/multithreaded functionality.
  23
  24 - Sligthly More documentation. With the generation of man pages and
  25   multiple pages for the website, it does already look acceptable.
  26   It should still get better of course - kinda newbie friendly *g*
  27
  28 - Boris Schäling likes to open a zzip archive in memory.
  29
  30 KNOWN PROBLEMS
  31
  32 The win32 compilers need each a different config.h derivate that
  33 matches both the headers shipped with the compiler and installed
  34 with updates of the SDK. There is no autoconfigure on win32 as
  35 that - unless you install some unix tools along.
  36
  37 The sparc-sun-solaris2.* will utter warnings for "char subscript"
  38 which is caused by isdigit() from ctype.h - this will NOT FIX as
  39 it is only in the example source code and we want to keep those
  40 lean and mean to make them easy to adopt by developers.
  41
  42 The hppa1.1-hp-hpux10.20 did show spurious problems of making
  43 shared libraries - this may well fix with an update of the
  44 libtool package, the libtool 1.4 is dated 2001/04/24
  45
  46 There are reports of misaligned access to some zip fields that
  47 I would guess to be on little-endian non-x86 platforms. The current
  48 bytewise access of multibyte fields is targetted towards the
  49 bigendian unix machines. The fix would need to go to fetch.h but
  50 so far no response came about as that one could test a solution.
  51
  52 There are spurious reports of users on win32 platforms that tell
  53 of some problems with a specific zip file they have but it was
  54 not possible so far to recreate an environment abroad to show
  55 the problem too. One can not say if that is due some general
  56 instability out of DLL hell, or if there is a bug hiding somewhere.
  57 Please send all those zip files to the maintainer, perhaps it
  58 can help to find the real cause (I doubt it is in zziplib, but..)
  59
  60 Since lately the xml docbook tools have hardened the checks on the
  61 input xml that is used for manpage generation. Interestingly the
  62 resulting manpages are still okay but one should try to fixaway the
  63 warnings as may be later the result would lead to garbage output
  64 due more changes in the tools. Needs to change the xml generator
  65 used in zzip (a python script).
  66
  67 TESTED PLATFORMS
  68 sparc-sun-solaris2.6/gcc2.95.3
  69 sparc-sun-solaris2.8/gcc2.95.3
  70 hppa1.1-hp-hpux10.20
  71 i686-mandrake-linux-9.0/gcc3.2
  72 i686-mandrake-linux-9.1/gcc3.2.2
  73 i686-debian-linux-2.2/gcc2.95.2
  74 i386-unknown-freebsd4.7/gcc2.95.4          (formerly with wrapwrap)
  75 powerpc-apple-darwin5.5                    (formerly with wrapwrap)
  76 alphaev67-unknown-linux-gnu/gcc2.95.4      (that's a 64bit platform)
  77 i386-ms-win32/msvc6
  78 i386-ms-win32/msvc7
  79 i386-ms-win32/mingw+msys
  80 ... and probably a lot of others not known to the maintainer.
  81
  82 Additionally, note that Sourceforge has discontinued their compilefarm
  83 server laboratory. That makes it unlikely that proper support for
  84 crossplatform functionality can be provided. Expect a compile problem
  85 here or there - the code however should be prepared to get around any
  86 problems easily. Send patches! (especially Linux distributions makers
  87 are usually not sending their patches to upstream maintainers).
  88
  89 Note: the latest cross platform tests are done indirectly by using
  90 the build.opensuse.org rpm packaging where one can run "make check"
  91 just before doing the "make install" of the compiled library.
  92
  93
  94 SUSE BUILDSERVER INFO
  95
  96 I: A function overflows or underflows an array access. This could be a real error,
  97 but occasionaly this condition is also misdetected due to loop unrolling or strange pointer
  98 handling. So this is warning only, please review.
  99 W: zziplib arraysubscript ../../zzip/memdisk.c:114
 100
 101 I: File is compiled without RPM_OPT_FLAGS
 102 W: zziplib no-rpm-opt-flags <cmdline>:../../SDL/SDL_rwops_zzcat.c, ../../SDL/SDL_rwops_zzip.c
 103
 104 I: Program is likely to break with new gcc. Try -fno-strict-aliasing.
 105 W: zziplib strict-aliasing-punning ../../zzip/file.c:275
 106 W: zziplib strict-aliasing-punning ../../zzip/fseeko.c:99, 126, 147, 158, 182, 281, 288, 301, 360, 539, 543, 546, 563
 107 W: zziplib strict-aliasing-punning ../../zzip/memdisk.c:181, 182, 183, 185, 186, 187, 188, 189, 192, 193, 194, 195, 247, 455, 456
 108 W: zziplib strict-aliasing-punning ../../zzip/mmapped.c:277, 289, 311, 314, 339, 340, 393, 397, 410, 438, 440, 443, 444, 549, 551, 552, 558, 559, 561
 109 W: zziplib strict-aliasing-punning ../../zzip/zip.c:318, 320, 321, 322, 339, 341, 342, 343, 484, 485, 486, 497, 498, 499, 500, 501
 110 E: zziplib 64bit-portability-issue ../../zzip/memdisk.c:112
 111 System halted.