As per previous posts, the -pbatard branch now has had the requirement
for cdio_config.h (and cdio_unconfig.h) removed .
With regards to its impact on the includes, I'm confident that the
dependency for stdbool.h/HAVE_STDBOOL_H should be pretty much squared
off (it's very straightforward to duplicate, and the
'__bool_true_false_are_defined' guard seems universal), as well as the
ones for HAVE_S_ISSOCK & HAVE_S_ISLNK --especially with the later
commits that create a new filemode.h in lib/driver and remove the need
for S_ISSOCK & S_ISLNK in the API altogether.
With regards to stdint.h/HAVE_STDINT_H, I've also followed through with
expecting it to be available by default, except on the few platform(s)
we specify. Most platforms I know should be able to locate an stdint.h
if missing, so even if it is not available by default, I do not see it
as that penalizing for libcdio users.
The next concern then is with sys/types.h and unistd.h. Basically, these
seem to be required for the following types to be defined, as required
by the API:
Currently, I am not aware of any platform that we ought to support that
shouldn't have sys/types.h, and all the sys/types.h I see appear to
define all of the above (expect for MSVC, but this will be addressed
Therefore, the patch removes the unistd.h dependency altogether and
currently expects sys/types.h to be available everywhere (see the new
include/cdio/types.h ). However, since it's impossible to check every
system out there and there's a real possibility that some really don't
have sys/types.h (or use unistd.h instead), I added a very explicit
comment to contact the mailing list if the include is not found, so that
we can add special cases accordingly. Libcdio users cannot fail to see
that comment if the compilation chokes on sys/types.h so we should be
fairly safe there as well.
The one last item that we have to deal with then is "inline", as
currently used in bytesex###.h and utils.h. Unfortunately, inline is
only guaranteed available for C++, and pure C is expected to be a mixed
bag. At least if you use gcc with option -ansi (and without
-fgnu89-inline) or MSVC in pure C, inline is not available. However
__inline__ or __inline respectively, are available as replacement.
Thus my proposal is to replace all the stray inline from these includes
with CDIO_INLINE and add the following at the beginning of bytesex###.h
This has now been applied in the -pbatard branch .
I think these changes should leave the API in better shape for the
future, but since they may break existing applications, it might be
worth bumping the CDIO_API_VERSION from include/cdio/cdio.h when merging
these commits onto mainline.