Removing ULONG

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Removing ULONG

Regina Henschel
Hi all,

I'm currently looking in ScBinomDist to remove the PushNoValue() cases.
I see a lot of ULONG there and as Carsten has announced, that ULONG will
be removed, my question now, how I should replace it.

The parameters n (total number of independent trials) and x (number of
successful trials) are integers in ODF. As we store them in double, they
are exact up to 48Bit. The code has some for-loops up to this
parameters. What type shall I use for the index i in the loops?

Kind regards
Regina



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing ULONG

Carsten Driesner-3
Am 01/17/2011 11:12 PM, schrieb Regina Henschel:

> Hi all,
>
> I'm currently looking in ScBinomDist to remove the PushNoValue() cases.
> I see a lot of ULONG there and as Carsten has announced, that ULONG will
> be removed, my question now, how I should replace it.
>
> The parameters n (total number of independent trials) and x (number of
> successful trials) are integers in ODF. As we store them in double, they
> are exact up to 48Bit. The code has some for-loops up to this
> parameters. What type shall I use for the index i in the loops?
Hi Regina,

ULONG is the most problematic type in tools/solar.h. The current mapping
is that ULONG is the same type as sal_uIntPtr (which means an unsigned
integer which can store a pointer). That's not exactly true for every
code which I have seen during the conversion. There is old code which
assumes that ULONG is the same type as sal_uInt32. There is also other
code which assumes that ULONG can store a pointer. Both assumptions are
true for (as far as I know) all 32-Bit systems but not for 64-Bit!
Therefore we "created" a new type called "sal_uLong" (typedef
sal_uIntPtr) which should only be a temporary solution. Hopefully
developers who work on code, exchange sal_uLong with the correct type
depending on the context. The new type "sal_uLong" was only used for the
semi-automatic tools type removal and should NEVER be used for new code.
Normally it's safe to use unsigned long or a sal_uInt-type. Attention
must be paid to code which is used to stream to/from the file system.
Using sal_uIntPtr there would be a real problem due to the difference
between 32- and 64-Bit systems.

Regards,
Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Removing ULONG

Eike Rathke-6
In reply to this post by Regina Henschel
Hi Regina,

On Monday, 2011-01-17 23:12:16 +0100, Regina Henschel wrote:

> I'm currently looking in ScBinomDist to remove the PushNoValue()
> cases. I see a lot of ULONG there and as Carsten has announced, that
> ULONG will be removed, my question now, how I should replace it.
>
> The parameters n (total number of independent trials) and x (number
> of successful trials) are integers in ODF. As we store them in
> double, they are exact up to 48Bit. The code has some for-loops up
> to this parameters. What type shall I use for the index i in the
> loops?

Such loop variables were intentionally declared as ULONG to use the
maximum size integer a system provides, back in time when ULONG was
typedef'ed to unsigned long. On the other hand, I can hardly imagine
a spreadsheet where more than 2^32 cells are passed as a data range..

A safe approach would be to use sal_uInt32 and introduce a GetuInt32()
method (internally using GetDouble()) to obtain an argument that is to
be converted into a sal_uInt32 and let that set an error if the
approxFloor()'ed argument value is greater than SAL_MAX_UINT32. We may
introduce errNumericOverflow to signal this and distinguish from other
errors.

  Eike

--
 OOo Calc core developer. Number formatter stricken i18n transpositionizer.
 Signature key 0x87F8D412 : 2F58 5236 DB02 F335 8304  7D6C 65C9 F9B5 87F8 D412
 OpenOffice.org Engineering at Oracle: http://blogs.sun.com/GullFOSS

attachment0 (200 bytes) Download Attachment