[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180821160725.GC4723@thunk.org>
Date: Tue, 21 Aug 2018 12:07:25 -0400
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Lukas Czerner <lczerner@...hat.com>
Cc: linux-ext4@...r.kernel.org
Subject: Re: [PATCH] e2fsprogs: clean up architecture dependent header files
On Tue, Aug 21, 2018 at 04:59:56PM +0200, Lukas Czerner wrote:
> Currently blkid_types.h and ext2_types.h header files are architecture
> dependent which is messy and creates problems when building packages for
> multilib architectures. The API should really ideally be architecture
> independent.
>
> Since we already include stdint.h use the exact-width integer types to
> define the specific __[u,s][8,16,32] types which is easy to do. In
> future we might want to get rid of this entirely and just use stdint.h
> types directly.
We were *supposed* to have only used stdint.h if it exists:
#ifdef HAVE_STDINT_H
#include <stdint.h>
#endif
However, it looks like we've gotten sloppy and there are places such as
lib/ext2fs/crc32c.c where we don't protect the stdint inclusion and
used stdint.h types --- and no one has complained.
In particular, the last holdout I'm aware of where this was a problem,
MSVC (Microsoft Visual Studio's C compiler) is apparently OK now.
(MSVC only got around to adding stdint.h *TEN YEARS* after C99 was
released, in 2010. And anyone who hasn't upgraded to MSVC 2010 or
later in 2018 gets zero sympathy from me. :-)
So sure, we can try using stdint.h, and hopefully nothing will break.
But the main reason why I'm interested is build simplification.
Specifically, see if we can get rid of all uses of HAVE_STDINT_H and
then get rid of the stdint.h test in configure.ac. Even better, this
should also allow us to stop making *_types.h generated files, which
means they should be renamed to *_types.h. This will allow us to get
rid of config/parse_types.sh, and the Makefile.in's which used
parse_types.sh.
Would you be interested in taking a look at that cleanup?
- Ted
P.S. I'm curious why you had move the #include's around in e2freefrag.c?
Powered by blists - more mailing lists