On 28 November 2012 13:10, Rich Felker <[email protected]> wrote: >> >> You seem to ignore part of my replies. I explained that 32-bit >> syscalls need to be present >> so existing applications can link and work as expected. For example, >> many applications still use >> stastfs() instead of statfs64(). As a result of which, we still need >> the 32-bit structures around. > > On 64-bit machines, statfs and statfs64 are the same function. > Moreover, whenever _FILE_OFFSET_BITS is defined to 64 (which should > always be done; mixing programs compiled with different settings can > lead to subtle and dangerous bugs with file descriptor inheritance) > statfs is statfs64. Nobody should ever be calling statfs64 by name. > >> And the 32-bit structure you will pass to the INLINE_SYSCALL() will >> end up in kernel space so it has to > > It never ends up in kernelspace on no-legacy-syscall archs because > THERE IS NO SUCH SYSCALL. You have to make the statfs64 syscall > instead, and the 32-bit structure only exists by virtue of whatever > translations you do in userspace.
No need to write in capitals. I am trying to understand what the problem is and what an acceptable solution would be. So you prefer a solution where _FILE_OFFSET_BITS is always defined for new architectures instead of having a struct statfs with a similar layout with statfs64 but with 32-bit members and padding? > >> have a similar layout with the kernel statfs structure which ( I >> already said that ) is always defined in new architectures >> in $KERNEL/include/asm-generic/statfs.h. So even if we provide our own >> in uClibc, we can't change the kernel one. >> Do I miss something? > > Yes. You miss that THERE IS NO KERNEL ONE on these archs. Again, please no capitales. The 32-bit structures are defined for every new architecture http://lxr.free-electrons.com/source/include/asm-generic/stat.h http://lxr.free-electrons.com/source/include/asm-generic/statfs.h As you can see the 32-bit structures are defined for these architectures even if they don't have the 32-bit sycalls. But like I said on my next email, I understand that this is irrelevant as these arches don't have the 32-bit syscalls which need these structs. > >> > There is no such thing as a "positive pointer". Pointers do not have >> > sign. >> >> OK I meant an arbitrary positive integer that the user can pass in the >> statfs(). Many LTP tests does that. The only different is that >> these tests will crash libc in new architectures but will return -1 >> on old ones. > > Your proposed "test that the pointer is positive" nonsense makes it > impossible to use statfs. *Most* uses of statfs involve a pointer > which, when cast to int, becomes a negative number (due to being on > the stack). I already said that I will remove this pointless check. It's already gone in my git repo -- Regards, Markos _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
