[Libreoffice] [PATCH] Removed dependencies on tools/solar.h

[Caolán McNamara]

On Tue, 2011-01-04 at 10:34 -0500, Kohei Yoshida wrote:
> On Tue, 2011-01-04 at 01:57 -0600, Norbert Thiebaud wrote:
> > Note:
> > C99 has been a standard for quite a while now. why are we not using
> > the standardized type for these. that is:
> > int8_t uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t,
> > uint64_t, intptr_t, uintptr_t,...
> 
> Actually, I've been a proponent of these data types myself.  So I
> personally would much prefer using these types over sal_Foo data types.
> So, no objection there from me. :-)

FWIW, a little gotcha here is that due to some historical oddities
(win16 days I guess) a sal_uInt32 is typedefed from "long" on 32bit
platforms and from "int" on 64bit platforms. So the mangled C++
signatures of exported methods from the "public api" ure C++ libs export
that detail, so changing/typedefing a sal_uInt32 to uint32_t (assuming
that this is the same type as int on 32bit) would change the exported
uno ABI on 32bit. So existing binary 32bit extensions will probably stop
working, which may not be an argument against it, but is something to
consider anyway.

See e.g. cppu/util/*gcc*.map and the ? wild-card to see some of the
existing hack-arounds that the differing typedef of sal_[u]Int32
requires.

C.