On Wed, Nov 28, 2012 at 11:17:54AM +0000, Markos Chandras wrote: > On 28 November 2012 10:58, Vineet Gupta <[email protected]> wrote: > > Precisely - now we are all on same page. So collecting all the ideas so > > far for conclusion: > > > > (3) Have stat/stat64 with same overall layout but stat will internally > > have 32 bit items (with appropriate padding) - allowing both structs to > > be used in the 64bit syscall interface. This needs no interworking crap > > except for some overflow checks (by testing high word). > > I am currently doing that. 32-bit members and 32-bit padding for the > new struct statfs/stat. I am thinking we may have problems with > endianness? For example in little endian arches the padding should > come first whereas for big endian the pudding should come > second or something like that. We can go away with using 64-bit member > but this might break in some cases where the userland application does > not use typeof() to get the type of the struct member, but assumes > it's 32-bit or something.
This is not acceptable. It even breaks printf. For example if the application's configure script has determined that off_t is int, passing an off_t member of "struct stat" for a "%d" specifier should work. Simply have an #ifdef based on endianness to order the off_t field and the padding field appropriately. Rich _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
