While looking into the dlclose issue, I ran into this problem that I never noticed before.
I got this warning: ../ldso/dl-hash.c:142: warning: pointer targets in passing argument 1 of '_dl_elf_hash' differ in signedness My Research (uClibc 0.9.28.3): include/bits/elfclass.h:14:typedef uint32_t Elf_Symndx; ldso/ldso/dl-hash.c:60:static inline Elf_Symndx _dl_elf_hash(const unsigned char *name) ldso/ldso/dl-hash.c:142: elf_hash_number = _dl_elf_hash(name); ldso/ldso/dl-hash.c:138: unsigned long elf_hash_number, hn; Here, _dl_elf_hash returns a "uint32_t" and elf_hash_number, is an "unsigned long". Looking up uint32_t on the web, i get: typedef unsigned long int uint32_t from: http://linux.die.net/man/3/uint32_t Which means that the usage of unsigned long in replacement of uint32_t "should" work. However, looking on my /usr/include/stdint.h, i see: #ifndef __uint32_t_defined typedef unsigned int uint32_t; # define __uint32_t_defined #endif This means that uint32_t can at any point be defined as an "unsigned int" and an "unsigned long" depending on whether __uint32_t_defined was defined before the stdint.h is included. Furthermore, the fact that "unsigned long" is being used in place of "uint32_t" is dangerous if some header defines uint32_t as something other than "unsigned long" (which is what happened here). I also looked at uClibc 0.9.29 just to see if this specific issue still exists. It does, only the line numbers are slightly different. -- Kevin Day _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
