Re: [Libcdio-devel] RFC: libcdio to remove it's version of bool and require <stdbool.h> ?

[Rocky Bernstein]

I'd like not to add more layers of of complexity. Otherwise the only one
who will understand this is Thomas. And even there, he has lots of
questions that require someone's (usually my) involvment.

If we have to break things to simplify so be it. I'd like to leave the
complexity for those things that really need it, like handling multiple
ISO9660 extents.

On Sun, Jul 15, 2018 at 5:54 AM, Thomas Schmitt <address@hidden> wrote:

> Hi,
>
> Rocky Bernstein wrote:
> > stdbool.h is POSIX. See http://pubs.opengroup.org/onlinepubs/9699919799/
> > Thoughts?
>
> ... and earlier in a different thread:
> > >  That will probably break the ABI, but I think I'm okay with that.
>
> Indeed libcdio should do something about the riddling error messages which
> appear if <stdbool.h> is included after <cdio/iso9660.h>. (In those
> messages, "bool" is about the least prominent name.)
>
> But breaking the ABI is of course not my personal favorite.
>
>
> include/cdio/types.h already tries to communicate with "All the stdbool.h"
> by defining macro __bool_true_false_are_defined .
> Obviously my local stdbool.h does not really understand this. (gcc -H says
> it is /usr/lib/gcc/x86_64-linux-gnu/4.9/include/stdbool.h .)
>
> How about waving more flags there ?
>
> The following code change compiles although in iso9660_private.h the header
> <stdbool.h> is included after <cdio/iso9660.h> which in all branches would
> cause compile time errors:
>
> =========================================================================
>
> diff --git a/include/cdio/types.h b/include/cdio/types.h
> index dc7e478..6c1a057 100644
> --- a/include/cdio/types.h
> +++ b/include/cdio/types.h
> @@ -104,11 +104,15 @@ typedef uint8_t ubyte;
>  #endif
>
>  #ifndef __cplusplus
> +#ifndef _STDBOOL_H
>
> -/* All the stdbool.h seem to define those */
> +/* All the stdbool.h seem to define those (but not all seem to obey) */
>  #ifndef __bool_true_false_are_defined
>  #define __bool_true_false_are_defined 1
>
> +/* Keep conflicting definitions out, now that own ones get created. */
> +#define _STDBOOL_H
> +
>  #undef bool
>  #undef true
>  #undef false
> @@ -122,6 +126,7 @@ typedef uint8_t ubyte;
>  #define false 0
>
>  #endif /* __bool_true_false_are_defined */
> +#endif /* _STDBOOL_H */
>  #endif /*C++*/
>
>    /* some GCC optimizations -- gcc 2.5+ */
> diff --git a/lib/iso9660/iso9660_private.h b/lib/iso9660/iso9660_private.h
> index c5e1393..53b0264 100644
> --- a/lib/iso9660/iso9660_private.h
> +++ b/lib/iso9660/iso9660_private.h
> @@ -32,6 +32,9 @@
>
>  #include <cdio/types.h>
>
> +/* <<< only for a test */
> +#include <cdio/iso9660.h>
> +
>  #ifdef HAVE_STDBOOL_H
>  # include <stdbool.h>
>  #endif
>
> =========================================================================
>
> I see few potential for regression:
> This change can hardly break existing applications, because they would run
> into the compiler errors if they included stdbool.h after cdio/types.h.
> If they included stdbool.h before cdio/types.h, then "#ifndef _STDBOOL_H"
> should not be reached at all, and even if so it should do no harm, because
> the first inclusion of stdbool.h should keep out further inclusions of
> itself.
>
>
> Have a nice day :)
>
> Thomas
>
>
>