[pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool

David Henningsson david.henningsson at canonical.com
Sun Jul 1 23:45:42 PDT 2012


On 06/30/2012 12:36 PM, Tanu Kaskinen wrote:
> Hi,
>
> We handle booleans with these definitions:
>
> /* This type is not intended to be used in exported APIs! Use classic "int" there! */
> #ifdef HAVE_STD_BOOL
> typedef bool pa_bool_t;
> #else
> typedef int pa_bool_t;
> #endif
>
> #ifndef FALSE
> #define FALSE ((pa_bool_t) 0)
> #endif
>
> #ifndef TRUE
> #define TRUE (!FALSE)
> #endif
>
> As far as I know, the "bool" data type is a feature of C99, and we also
> rely on other other C99 features, so I don't think there's any benefit
> in having the HAVE_STD_BOOL check, or compatibility problems if we drop
> the check. We could define pa_bool_t as bool unconditionally. And if we
> do that, then we could as well start using bool directly instead of
> wrapping it in pa_bool_t.
>
> Therefore, I propose that we deprecate pa_bool_t (I have a feeling that
> someone has proposed that already before, but that discussion didn't go
> anywhere). My proposal for the transition strategy is that pa_bool_t is
> kept for now, but it would always be defined as bool. New boolean
> variables should not use pa_bool_t. Old pa_bool_t uses would be
> converted gradually like was done e.g. with pa_streq(). There was
> recently a patch that changed all remaining strcmp() uses into
> pa_streq(), and if someone wants to write a patch that converts all
> pa_bool_t instances into bool in one go, that's fine for me.
>
> What do others think?

I don't think there is any reason to not do s/pa_bool_t/bool/g. Probably 
the reason for this might be historical, as some compilers may have 
supported some C99 features but not all of them (Microsoft compilers 
come to mind).

It might make sense to keep something like

#ifndef HAVE_STD_BOOL
typedef int bool;

...or just remove all of it, make configure fail if stdbool.h is not 
present, and insert something like the above if we find we broke a 
compiler we want to support.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic




More information about the pulseaudio-discuss mailing list