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

Norbert Thiebaud nthiebaud at gmail.com
Tue Mar 29 22:47:36 PDT 2011

On Tue, Mar 29, 2011 at 6:51 PM, Bjoern Michaelsen
<bjoern.michaelsen at 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 :

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
which is almost right, it should be

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


More information about the LibreOffice mailing list