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.