Any plan to substitute "long" with "sal_Int32" ?

tora - Takamichi Akiyama <[email protected]> Thu, 14 Apr 2011 01:17:50 +0900
Newsgroups gmane.comp.openoffice.devel.tools
Message-ID <[email protected]>
Hi,

Any plan to substitute "long" with "sal_Int32", at least in gen.hxx?

=== DEV300_m106/tools/inc/tools/gen.hxx
class Pair
{
public:
     long                nA;
     long                nB;
...

class Point : public Pair
{
...

class Size : public Pair
{
...

=== DEV300_m106/sal/inc/sal/types.h
typedef ... sal_Int32;

=== OpenSolaris x86 ... 64bits OS
$ cd DEV300_m106/sal/typesconfig
$ cc typesconfig.c
$ file a.out
a.out:		ELF 32-bit LSB executable 80386 Version 1 [FPU], dynamically linked, not stripped
$ ./a.out | egrep 'sizeof.+(long|void)'
sizeof(long)		= 4
sizeof(long long)		= 8
sizeof(void *)		= 4

=== Fedora 10 x86_64 ... 64bits OS
...
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
$ ./a.out | egrep 'sizeof.+(long|void)'
sizeof(long)		= 8
sizeof(long long)		= 8
sizeof(void *)		= 8

On Solaris 64bits OS, cc creates a 32 bit application by default while
on Linux 64bits OS, it seems cc creates a 64 bit application by default.

I prefer a Solaris way. Because most applications do not use a memory
beyond 4GB. In that case, a 8 byte pointer and long integer are just
waste of money or against green, I think.

It is okay to use 8 byte pointers if the application needs more than 4GB.
What about 8 byte long integers?
How does it help our OpenOffice.org?

This post is not a criticism. I do not encounter any problem with that
so far. Just curious.

Best regards,
Tora
-- 
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help