Tim Potter writes: > Hello. I'm using the libcdio library for command line access to data > inside a ISO file. I've run in to a couple of bugs though in the CVS > version downloaded a couple of days ago.
Using CVS is good. I'm not sure any of the previous releases will do as well. The ISO code has been heavily used for VCDs but that is a specialized and well-controlled environment. > The code included when stdbool.h is not found is broken. It #define's a > bool to be an enum which, under gcc 3, is four bytes long. This totally > screws up the parsing of directory entries which presumably do something > like ndx += sizeof(bool) somewhere. Here's a patch: The patch looks okay - in fact I've applied it based on your description of the problem. However I don't see anything that looks like ndx += sizeof(bool) in libcdio or anywhere else and I've used the most sophisticated tools (Google desktop search ;-) So could you be more specific as to what is using ndx += sizeof(bool)? > Also, I'm not convinced that having types.h depend on autoconf variables > is such a good idea. As an external user of the library (i.e only files > installed in /usr/local/lib and /usr/local/include) all the > "workarounds" are activated since I didn't add the various HAVE_FOO_H > defines to my command line. This is how I discovered the bool/enum > problem. Well I guess the advantage from libcdio's standpoint is that I guess it helps discover those bugs! But yes, I think your are correct that it isn't the greatest thing to have libcdio/types.h depend on autoconf variables. When something similar like this came up in libcddb, what I did was have say a cdio/libcdio_config.h include file that was used when C preprocessor variable HAVE_CONFIG_H isn't defined. This backup configuration file *is* generated from autoconf, and it doesn't have to have all of the definitions, just the ones needed in the public header(s). You can look at say the libcddb package if my explanation isn't clear. How do folks feel about this? Any better suggestions? _______________________________________________ Libcdio-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/libcdio-devel
