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

[Norbert Thiebaud]

On 1/4/11, Caolán McNamara <caolanm at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
>