On Tue, Aug 21, 2018 at 09:53:53AM -0400, Theodore Y. Ts'o wrote: > On Tue, Aug 21, 2018 at 02:14:44PM +0200, Lukas Czerner wrote: > > > > The reason why I want to get rid of it is that the API should be > > platform independent (it is not in this case). And it is causing us to > > use some hacking in the spec file if we want to building a package for > > multilib systems. Hi Ted, sorry I just noticed your reply after I sent my patch. > > When you say "not platform independent" do you mean that there are > cases where a particular function parameter is 32-bit versus 64-bit? > Or that there are cases where the *size* is the same, but it might be > a "long" versus an "int" across different platforms? > > And is the problem that you want to use the same package for the RPM > equivalent of "libext2fs-dev" across on a 32-bit and 64-bit multilib > system? > > And where is it that we are not platform-independent? The issue is in the header files ext2_types.h and blkid_types.h and those are going to differ depending on architecture. See: ... #if (@SIZEOF_INT@ == 2) typedef unsigned int __u16; #else #if (@SIZEOF_SHORT@ == 2) typedef unsigned short __u16; ... but in e2fsprogs we only create one ext2_types.h which can't really be shared with 32-bit and 64-bit platforms. The fix is rather easy, we just rename the header file to appropriate name (ext2_types-i386.h for example) and create a wrapper header that will include the right one for the right arch. I'd just like to see if and how can we clean this up because I do feel that it's not exactly right. > > > First of all let me ask why should we be using those __u.. __s.. types > > when we could be using types from stdint.h the fact is that we're > > already including it in the ext2_types.h anyway and no one seems to be > > complaining. > > Part of it is bcause e2fsprogs predates C99. The other is that what > was considered more important was that we were consistent with > asm/types.h, which is actually what we do on Linux systems: > > % ./config/parse-types.sh > checking for __uNN types... using <asm/types.h> > % cat asm_types.h > #define __S8_TYPEDEF __signed__ char > #define __U8_TYPEDEF unsigned char > #define __S16_TYPEDEF __signed__ short > #define __U16_TYPEDEF unsigned short > #define __S32_TYPEDEF __signed__ int > #define __U32_TYPEDEF unsigned int > #define __S64_TYPEDEF __signed__ long long > > These types were taken directly from /usr/include/asm/types.h, because > we want very much to be consistent with the kernel types: > > if echo '#include <asm/types.h>' | $CPP - 2> parse-types.log | \ > sed -f sed.script | grep '^#' > asm_types.h; then > echo "using <asm/types.h>" > else > echo "using generic types" > fi > > So this implies that on Fedora / RHEL either asm/types.h doesn't > exist, or it is not consistent on different platforms? Not sure how did you come to this conclusion, but no asm/types.h is not the problem. On linux most of the blkid_types.h should really be irrelevant since we should be using linux/types.h, but we're not even consistent in that. -Lukas > > - Ted
