Maybe if we give a small example of where things will go horribly wrong
on a 64-bit system with a NUMERIC DIGITS setting of 9 then people will
have a better idea of what the impact will be.
Here is a small sample.
a = copies('A', 99888777666555444) /* perfectly acceptable for 64-bit
ooRexx */
c = half(length(a))
d = substr(a, 1, c) /* this will not give the correct result! */
return
half: procedure
return arg(1) / 2
In this example the return value of the half function will not be what
you expect because the procedure subkeyword will cause the NUMERIC
DIGITS setting to revert to 9. Digits will be lost and any subsequent
operations on the return value will not be precise.
In order to prevent this type of aberation a programmer will need to
look at every procedure in a ported 32-bit program in order to determine
if a larger setting is being inadvertently cancelled out in a procedure.
What this really means is that if you have a program the works on large
objects (like very large strings) in a 32-bit environment and then port
it over to a 64-bit environment, when the string objects start to grow
beyond what a 32-bit environment can handle then the program will become
incorrect over time. I believe this is a worse condition than the
alternative of upping the NUMERIC DIGITS default setting.
Just my 2 cents worth.
David Ashley
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
