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?
