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


On 1/4/11, Caolán McNamara <caolanm@redhat.com> wrote:
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.

1/ we can always follow the same restriction than with sal_Bool/bool
(that is sal_* for Uno API, and native for the rest)
2/ the aforementioned problem  means that we would need to use
sal_uIntPtr and not sal_uInt32 to convert ULONG, in order to maintain
ABI.

maybe we could wait for a major version boundary and officially define
ULONG as uint32_t modulo the odd case where size_t or uint64_t is
really meant, advertise the migration breakage, and then change all
the related ULONG.
If we are going to do that, we might as well review all the sal_* type
as the same time.
If we going to break the ABI, we might as well take the opportunity to
set it straight across the board.

Norbert


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.

_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice


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.