On Mon, May 11, 2009 at 1:02 PM, Marc-Andr? Lureau<marcandre.lureau at gmail.com> wrote: > Hi Felipe! > > On Mon, May 11, 2009 at 12:56 PM, Felipe Contreras > <felipe.contreras at gmail.com> wrote: >> On Sat, May 9, 2009 at 3:14 PM, Lennart Poettering >> <lennart at poettering.net> wrote: >>> On Sat, 09.05.09 12:50, Felipe Contreras (felipe.contreras at gmail.com) wrote: >>> >>>> > pa_bool_t is used internally only. In the public API we only expose >>>> > ints. pa_bool_t is defined as _Bool on C99 and int on other >>>> > compilers. This discrepancy should not be visible to outside due to >>>> > ABI stability issues. >>>> >>>> Minor comment; if you include stdbool.h you can use 'bool' which IMHO >>>> is less ugly than _Bool. And I wonder what's the point of pa_bool_t... >>>> if the compiler doesn't have stdbool.h, then just define 'bool' as you >>>> would define pa_bool_t. >>> >>> There's not much difference between _Bool, and bool. Both are C99. >> >> Nope, the only difference is that 'bool' looks nicer :) >> >>> I guess 10 years after C99 it might be possible to drop C89 >>> support. But uh, the API uses int for all bools and we should stick to >>> it for now. >> >> This is what I meant: >> >> #if HAVE_STDBOOL_H >> #include <stdbool.h> >> #else >> typedef unsigned char bool >> #endif >> > > This is in public headers. That would mean you have to ensure that the > library and the client side are compiled both with the same config. > Which means practically requiring it to be C99, and thus the if is not > even necessary. Public headers? This is what Lennart said: pa_bool_t is used internally only. In the public API we only expose ints. -- Felipe Contreras
