Re: [Libreoffice] Purpose of easy task 'Get rid of sal_uLong' ?

On Tue, Mar 29, 2011 at 6:51 PM, Bjoern Michaelsen
<bjoern.michaelsen@canonical.com> wrote:
> Maybe we should use those even in sal/types.h by now?

sure, modulo a bit of work to teach windows about standards... as C99
is way to recent of a standard for MS to have implemented it... Poor
things, surely no sane person could imagine that they'd turn around on
a dime and add a pair of include file in their distribution in less
than 10 years and 4 major release of their C/C++ compiler. they simply
don't have the ressource to do that :
http://connect.microsoft.com/VisualStudio/feedback/details/345360/visual-c-should-support-c99

I think we could use <boost/cstdint.hpp> or
http://code.google.com/p/msinttypes/source/browse/trunk/stdint.h or
http://www.azillionmonkeys.com/qed/pstdint.h or write our own

> I still have some fear in me from all the places in sw and elsewhere,
> where I saw stuff like 0xFFFF and intended use of integer overflow. But
> maybe thats just paranoia.

I would argue that that practice is broken.
use instead  UINT[16/32/64/]_MAX (or SAL_MAXUINT[8/16/32/64] if you
_must_ use SAL_ :-) )

note that a quick grep in writer give 74 match for FFFF, about half of
them being clearly irrelevant to this discussion.
So I think that soothing your paranoia with regard to this particular
point should not be that hard to do :-)

Globally it is a bit harder to count as there are quite a bit of
noise, but there are indeed quite a few magic constant. It is almost
never ok to use actual numbers a in a source,
all these 0xFFFF to indicate 'not-positioned' or 'not-found', should
really be some kind of defined symbol.
For example, starmath/inc/dialog.hxx define
#define CATEGORY_NONE 0xFFFF
which is almost right, it should be
#define CATEGORY_NONE SAL_MAX_UINT16

Actually in general I'm indeed concerned with:
#define FOO nnnn
almost always that should be
#define FOO ((numeric_type_cast)nnnn)


Norbert