Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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.


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.