Issue 57674 - 64bit: Aliasing of SbxINT->SbxLONG?
Summary: 64bit: Aliasing of SbxINT->SbxLONG?
Status: CLOSED NOT_AN_OOO_ISSUE
Alias: None
Product: App Dev
Classification: Unclassified
Component: scripting (show other issues)
Version: 3.3.0 or older (OOo)
Hardware: All All
: P3 Trivial
Target Milestone: ---
Assignee: ab
QA Contact: Unknown
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-10 14:18 UTC by kendy
Modified: 2013-02-24 21:00 UTC (History)
4 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Aliasing of SbxINT->SbxLONG (586 bytes, patch)
2005-11-10 14:25 UTC, kendy
no flags Details | Diff
The second 'basic' patch. (19.69 KB, patch)
2005-12-14 12:54 UTC, kendy
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description kendy 2005-11-10 14:18:49 UTC
This is a patch I found while splitting ooo64bit02 CWS into smallers CWSes (to
make the QA easier).  Does it make sense?  If yes, do you please have a CWS
where you can commit this change?

Without this change, I get the following error during linking:

../unxlngx6.pro/slo/dllmgr.o: In function `SbiDllMgr::CallProc(void*, SbxArray*,
SbxVariable&)':
/local/ooo-build/ooo-build/build/src680-m138/basic/source/runtime/dllmgr.cxx:442:
undefined reference to `SbxValue::PutInt(unsigned int)'
collect2: ld returned 1 exit status

Thank you in advance!
Comment 1 kendy 2005-11-10 14:25:00 UTC
Created attachment 31334 [details]
Aliasing of SbxINT->SbxLONG
Comment 2 kay.ramme 2005-11-22 09:52:48 UTC
->Kendy: Martin Hollmichel suggested that you create a 64bit CWS to be
integrated into the master. Patches should be reviewed by project owners first,
so please take this issue back after review. Hope that sounds reasonable for you.

Andreas, please review the attached patch and send it back to Kendy afterwards.
Comment 3 ab 2005-12-14 09:06:07 UTC
->kendy:
I had a look at the patch now. I have to admit that I neither really understand 
the problem nor the fix. PutInt is declared in sbxvalue.cxx using the PUT macro:

PUT( PutInt, SbxINT, int, nInt )

int is used there as a native type and in SbiDllMgr::CallProc nInt also is declared 
as system int type. So why should the linker complain at all? I cannot see any
"unsigned" anywhere. Has there anything been changed to SbxINT handling in the 
64 bit context?

The fix only seems to avoid the symptoms of the problem but I would prefer to
understand and fix the problem. And by using PutLong instead of PutInt the Basic
return type is changed what seems to be strange for me.

Maybe you could give some more background?
Comment 4 kendy 2005-12-14 12:53:11 UTC
ab: Oh sorry, I forgot it goes together with a much longer & probably more 
important patch; sorry for that :-(  I'll attach it also. 
 
I am not an author of either of the patches, but wrt. the unsignedness, it's 
because int GetInt() and PutInt( int ) are changed to sal_uInt32 GetInt() and 
PutInt( sal_uInt32 ).  But it could be a bug... 
 
Generally - looking at the second patch - it seems to me that it is better to 
use fixed size types (sal_[u]Int{8,16,32,64}) instead of #if 
SAL_TYPES_SIZEOFINT == 2, etc. but no idea whether the patch does it right, 
unfortunately. 
 
Could you please have a look at it as well?  The main difference on the x86-64 
platform is that sizeof( long ) = 8 on Linux (but 4 on Win64 according to what 
I have heard - but 64bit Linux is my main concern ;) ). 
Comment 5 kendy 2005-12-14 12:54:31 UTC
Created attachment 32384 [details]
The second 'basic' patch.
Comment 6 kai.sommerfeld 2006-02-14 09:40:09 UTC
We will address this in OOo 2.0.3
Comment 7 kendy 2006-03-27 14:11:42 UTC
These patches seem to be not necessary with the current Caolan's work... 
Comment 8 ab 2006-04-27 18:09:28 UTC
Evaluation won't be possible for 2.0.3 any more -> 2.0.4
Comment 9 ab 2006-06-20 10:08:05 UTC
ab -> kendy: Are these patches still relevant at all?
-> 2.x for now
Comment 10 kendy 2006-06-20 11:58:49 UTC
I guess that no - we are building without them.  Parts of them could be of some 
value as cleanup (sal_* types instead of BYTE, INT*, etc.), but nothing too 
important.  Marking as INVALID - but please have a quick look.
Comment 11 Martin Hollmichel 2008-05-16 13:55:28 UTC
close issue.