Hi Michael, On Fri, 01 Apr 2011 16:34:06 +0100 Michael Meeks <michael.me...@novell.com> wrote:
> Hi guys,
>
> I see quite a staggering number of these things around the
> codebase:
>
> $ g grep '== sal_True' | wc -l
> 744
> sal_True is -1 - which is great for unsigned bit fields and
> all that - but - well, I am certain there are a whole host of
> creative errors around where a supposedly boolean value is neither 0
> nor -1, and of course these create serious trouble were we to convert
> to using plain 'bool' more widely.
>
> The question is - are others concerned about this, and/or
> should we have a (very) easy hack to fix it ?
>
> Thoughts ?
Just a crazy thought. Couldnt one build an office with:
struct sal_Bool
{
typedef unsigned char internal_type;
internal_type m_Value;
sal_Bool(const internal_type value) : m_Value(value)
{
OSL_POSTCOND(m_Value == sal_True || m_Value == sal_False,
"created sal_Bool that is not true or false");
};
sal_Bool& operator=(const sal_Bool& b)
{
m_Value = b.m_Value;
OSL_POSTCOND(m_Value == sal_True || m_Value == sal_False,
"assigned a sal_Bool that is not true or false");
return *this;
};
operator internal_type()
{
return m_Value;
};
};
injected and then run though a lot of code coverage (subsequenttests
again maybe) to get rid of the uncomfortable feeling that there might
be not true and not false sal_Bools around?
Of course that code should never end up on master.
If we find no anormalies that way that is no guarantee there never will
be some (sneaking in via a filter that does not normalize or something),
but at least we can be sure we dont break too much by moving:
if( some_sal_Bool == sal_True ) => if(some_sal_Bool)
if( some_sal_Bool == sal_False ) => if(!some_sal_Bool)
Best Regards,
Bjoern
--
https://launchpad.net/~bjoern-michaelsen
signature.asc
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
