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.
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?
> 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?
- Ted
