it's rather the absence of a patch rather than a patch to achieve this. i.e.
drop the 64bit value SvStream import/export support.

Created attachment 34319 [details]
patch

mostly because ULONGs are streamed to and from disk, they currently are 4byte
values, but would be 8byte values under 64bit. Patch attached to explicitly set
streamed values as sal_uInt32 as they are currently implicitly assumed to be.

cmc->pl: can you confirm you'd be happy with this patch and return it to me if
so for inclusion into sixtyfour02 workspace

set as patch

The problem here is that the patch as a whole is incompatible from vcl upwards.
The functional part in the streams is obviously correct, however the changes to
the headers make that patch binary incompatible.

So for 2.0.3 i think we should stay with ULONG at the API but use sal_uInt32 in
the streams. I agree that we should clean the API up, too, as soon as a binary
incompatible build comes up.

pl: Please, what exactly is binary incompatible?  ULONG -> sal_uInt32 is safe 
on 32bit architectures AFAIK... 

The types have the same size, but are mangled differently on different platforms
(long <->int). So any  C++ method that takes a ULONG parameter has a different
mangling as the same one with a sal_uInt32 parameter. Now if you exchange these
methods in vcl library, then everything dependent on vcl suddenly misses a
symbol unless it gets build again. This would cause the patch mechanism to break
since not all libraries are built on the same header. Currently the patch does
not contain all libraries that depend on vcl.

Of course, neither the official OOo build nor Novell's or RedHat's build would
be influenced by that, since they are always compiled from scratch and
completely installed like that. Nevertheless there are vendors (well at least
Sun ;-) ) who make use of the patch install sets which can be created by
honoring the PATCH flag given to files in scp2; these patches contain only the
files changed since the OOo 2.0 release.

well I can rejig *this* patch to just affect the internals of vcl and not the
api, but personally I'm surprised that the "compatable" rule is still active.
It's not one which I think anyone who hasn't worked in Sun is probably aware of :-)

pl: But I still think that the mangling is the same...    
    
tools/inc/solar.h:   
typedef sal_uIntPtr		ULONG;   
   
sal/inc/sal/types.h:   
#if SAL_TYPES_SIZEOFPOINTER == 4   
	typedef sal_uInt32          sal_uIntPtr;   
   
(Which is in turn   
#if SAL_TYPES_SIZEOFLONG == 4   
	typedef unsigned long     sal_uInt32;   
to "decrease" the confusion ;-) )   
   
Or does the typedef change the mangling?  I think that it does not:  
  
$ cat main.cc  
typedef unsigned long sal_uInt32;  
typedef sal_uInt32 sal_IntPtr;  
typedef sal_IntPtr ULONG;  
  
class C {  
public:  
    sal_uInt32 method( sal_uInt32 a, sal_IntPtr b, ULONG c ) {}  
};  
  
int main( int, char ** )  
{  
    C c;  
    c.method( 1, 2, 3 );  
}  
$ g++ main.cc -o main  
$ nm main | grep method  
080483fe W _ZN1C6methodEmmm 
$ c++filt _ZN1C6methodEmmm  
C::method(unsigned long, unsigned long, unsigned long)  

Created attachment 34340 [details]
alternative patch

cmc->pl: I assume this one is acceptable in that it doesn't touch the public api

cmc->pl: oops, you're not cced. Happy with the alternative patch ?

cmc: i'm perfectly happy with that, but in the meantime also with the first
patch, please see below.

kendy: sorry for the delay, but i wanted to check with solaris CC and the
windows compiler. It would seem that you are right, typdefs do not go into the
name mangling, so this particular change does not break binary compatibility as
long as the typedefs are all the same basic type.

no 1 committed to sixtyfour02 in that case

pl: No problem, thank you very much for checking! :-) 

Verified in sixtyfour02.

in m160