Created attachment 45165 [details]
Patches for stoc

Created attachment 45166 [details]
Patches for vos

Andreas, 

I mixed introspection and invocation :-), please take a look at the patch, apply
as appropriate and forward the bug later on to Hennes, for the VOS patch.

Thanks

  Kay

.

.

ab->cyhawk: I have some questions concerning the introspection.cxx related patch.

First, I agree with sb who commented in #i73468:
"For one, most of those places are probably better fixed by simply dropping the 
L suffix.  For another, please do not introduce any new C style casts in C++ code."
Any objections against just dropping the L suffix?

Second: What's the sense of changing e.g.
sal_Int32 iAllExportedMethod = 0L;  to
sal_Int32 iAllExportedMethod(0L);
I don't like this syntax for simple types and I don't see any effect concerning type
warning problems you might want to adress. So why not just also changing it to 
sal_Int32 iAllExportedMethod = 0;
as sb proposed?

STARTED, OOo 2.x

Makes sense to me. I've tried to add Rudolf Ferenc to the CC list but it looks
like email addresses can not be added. You can reach him at
ferenc@inf.u-szeged.hu though. He's from University Szeged and responsible for
this rule (all of the rules actually :)). He can better discuss the rationale of
it. I will send him an email and tell him to create an issuezilla account and
participate in these conversations if possible.

Still waiting for reaction from Rudolf Ferenc. If there will be none within
the next weeks I will change the code according to sb's and my proposal.

Hi! I'm Rudolf Ferenc, from the University of Szeged. Let me explain the
origin of the patches.
We analyzed a lot of already fixed bugs in the OOo source code and found that at
some point in time you started to build OOo on 64bit processors too. This
probably introduced lots of problems, because the size of 'long' changed from 32
to 64 bits. You used the 'long' type in many places and when these variables got
e.g. initialized, you used the form 'long lv = 0L;'.
To overcome the 32 vs. 64 bit issue you introduced the sal_Int32 type, which
means a 32bit value on both 32 and 64 bit machines (it depends on macros, see
types.h), and started to replace all occurrences of 'long' with 'sal_Int32', but
the e.g. '0L' integer literals remained there in many places. This can cause
compilation problems with 64 bit compilers (see e.g.
http://qa.openoffice.org/issues/show_bug.cgi?id=57396). The compiler complained
that it cannot find the called function, because it expects sal_Int32
parameters, but the function argument was of 'long' type).

ab->ferencr: So if I understood you correctly you see no objections against
dropping the L suffix. This also should solve the described problems.

Added to cws ab42

.

FIXED

ab->sb: Please verify in source code on cws04/ab42 stoc + vos

According to your suggestion from i73468 (quoted in my comment from May 23)
I did not apply the patches directly but removed the L suffixes instead.

verified by code review

.