Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On Thu, 2012-07-05 at 15:19 +0800, rong deng wrote: 2012/7/2 David Henningsson david.hennings...@canonical.com: 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). Does pulseaudio work on Windows? If it doesn't work at all, why should we bother ;) It does. :) People use it for streaming, and there's also a waveout sink/source. -- Arun ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
2012/7/5 Arun Raghavan arun.ragha...@collabora.co.uk: On Thu, 2012-07-05 at 15:19 +0800, rong deng wrote: 2012/7/2 David Henningsson david.hennings...@canonical.com: 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). Does pulseaudio work on Windows? If it doesn't work at all, why should we bother ;) It does. :) People use it for streaming, and there's also a waveout sink/source. Great. It's good to know. ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
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 ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On Mon, 02 Jul 2012 08:45:42 +0200, David Henningsson david.hennings...@canonical.com wrote: It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; I sincerely don't recommend that kind of hacks. int and bool are completely different things. The representation in memory may be different depending on the ABI. Furthermore, the conversion rule for the compiler are not the same. That can introduce subtle bugs on old compilers. I think it's best to fail explicitly than to hide bugs. -- Rémi Denis-Courmont Sent from my collocated server ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Transitioning from pa_bool_t to C99 bool
On 07/02/2012 09:26 AM, Rémi Denis-Courmont wrote: On Mon, 02 Jul 2012 08:45:42 +0200, David Henningsson david.hennings...@canonical.com wrote: It might make sense to keep something like #ifndef HAVE_STD_BOOL typedef int bool; I sincerely don't recommend that kind of hacks. int and bool are completely different things. The representation in memory may be different depending on the ABI. Furthermore, the conversion rule for the compiler are not the same. That can introduce subtle bugs on old compilers. I think it's best to fail explicitly than to hide bugs. bool / pa_bool_t is not used in the public API/ABI, there we use only ints (for the reasons you claim above, I believe). Does your point still stand even if it is only used internally? -- David Henningsson, Canonical Ltd. https://launchpad.net/~diwic ___ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
