user/sven/linux-2.4.git/lib, branch master

lib: fix again memcmp export issues in the arch ksyms only

2009-07-21T12:58:54Z

The last memcmp fix was not enough as Ralf Rösch just reported that it did not fix build issues caused by the first one on mips (redefined symbol). The proper fix finally consists in only exporting the symbol in the affected architecture, i386. The final code is closer to what it was prior to the first change. If other architectures experience similar issues as i386 did, we'll add the faulty symbols to their own export list. A cleaner solution would have consisted in always exporting the symbols in string.c regardless of the architecture as is done in 2.6, but this could have broken some existing external patches, which is not desirable at this stage.

lib: memcmp must be exported without module versioning

2009-07-21T05:03:03Z

Recent fix to export memcmp() for gcc 3.4 caused a lot of warnings on setups using CONFIG_MODVERSION=y. This symbol must be exported with EXPORT_SYMBOL_NOVERS, since we don't want its name to be mangled. Thanks to Solar Designer for reporting the issue. Signed-off-by: Willy Tarreau

lib: export memcmp for external modules to build with gcc 3.4

2009-07-19T23:25:16Z

When building external modules for a kernel built with gcc-3.4, it sometimes happens that the module depends on memcmp() which is not defined. x86 only relies on __builtin_memcmp() which is not always available on other gccs. Since the mapping of memcmp() to __builtin_memcmp() is performed using a #define, no memcmp() symbol is declared. We have to export it in lib/string.c, as in 2.6. Note that 2.6 also undefines a few other symbols and exports all symbols. Right now this does not seem absolutely necessary on 2.4, so let's not touch this for now.

Revert unnecessary zlib_inflate/inftress.c fix

2005-08-18T18:44:34Z

It turns out that empty distance code tables are not an error, and that a compressed block with only literals can validly have an empty table and should not be flagged as a data error. Some old versions of gzip had problems with this case, but it does not affect the zlib code in the kernel. Analysis and explanations thanks to Sergey Vlasov

[PATCH] fix RedBlackTree rb_next/rb_prev functions

2005-08-06T17:58:47Z

I have found a bug in the source of rbtree.c file in /lib. In Kernel 2.6 it's ok, but 2.4.31 has this error. We try to use it with the jffs2 source code and only with this fix it work's fine. Signed-off-by: Marcelo Tosatti

The gzip description is as good as the ChangeLog says it is -: "Set n to

2005-07-26T15:47:36Z

length of v, to detect improper tables" and "Don't accidentally grow j past z". The return 2 instead of the return 0 is so that we actually error out if we also get inproper tables (for some reason the code returned "OK" in such cases). Fix outstanding security bugs in the Linux zlib implementations. See: a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html b) http://bugs.gentoo.org/show_bug.cgi?id=94584 Signed-off-by: Tim Yamin Signed-off-by: Tavis Ormandy

initial v2.4 GIT import

2005-06-02T20:44:34Z