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 dev-unsubscr...@tools.openoffice.org
For additional commands send email to sy...@tools.openoffice.org
with Subject: help
