[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Libcdio-devel] removal of include/cdio/cdio_config.h

From: Pete Batard
Subject: [Libcdio-devel] removal of include/cdio/cdio_config.h
Date: Sun, 29 Jan 2012 15:36:31 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

As per previous posts, the -pbatard branch now has had the requirement for cdio_config.h (and cdio_unconfig.h) removed [1].

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:
- mode_t
- size_t
- ssize_t
- off_t

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 separately).

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 [2]). 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 and utils.h:

#if !defined CDIO_INLINE
#if defined(__cplusplus) || defined(inline)
#define CDIO_INLINE inline
#elif defined(__GNUC__)
#define CDIO_INLINE __inline__
#elif defined(_MSC_VER)
#define CDIO_INLINE __inline
#endif /* CDIO_INLINE */

This has now been applied in the -pbatard branch [3].

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.



[1];a=commitdiff;h=c46611553df657ed4c6a2af840bf3c84eeafb0ee [2];a=blob;f=include/cdio/types.h;hb=beb74e6f238eb3448ef0078b90e945b2791faa22 [3];a=commitdiff;h=787f8caed3a713d2506e199932436e49a32a3034

reply via email to

[Prev in Thread] Current Thread [Next in Thread]