[Info-vax] DCL Integer Overflow

[Robert A. Brooks]

On 7/2/2017 1:21 AM, mcleanjoh at gmail.com wrote:
> On Saturday, July 1, 2017 at 12:51:22 AM UTC+10, Stephen Hoffman wrote:
>> On 2017-06-30 09:06:16 +0000, GerMarsh said:
>> 
>>> I wonder if someone will fix the old integer overflow which has been 
>>> there since the year dot...
>> 
>> As you're aware, DCL uses signed 32-bit integers on a two's complement 
>> machine.   What you've showed is what happens.  Changing that involves 
>> adding support for unsigned integers or switching to 64-bit integers or 
>> other extended-precision.  Adding a 32-bit unsigned type adds one bit, and
>> probably not worth the effort of the changes in isolation), and will
>> require syntax hackery and will break some code.    Short of adding 64-bit
>> support or other substantial changes, probably the only improvement in the
>> existing context is issuing an overflow error here, and that'd undoubtedly
>> break some existing code.  Adding 64-bit support — without some ugly
>> compatibility syntax hackery and/or without incurring a conversion or
>> migration to a new DCL64 interpreter — will also break some existing DCL
>> code, so...   Whatever happens breaks (some) code.   If (some) code is to
>> be broken, then it's incumbent to move forward far enough to really warrant
>> the migration effort involved; to not putter around the edges of DCL and
>> not add anything interesting and necessary and worth using.  Make it worth
>> the effort of migrating.
>> 
>> -- Pure Personal Opinion | HoffmanLabs LLC
> 
> From the June 2017 VMS Roadmap, under "Research Areas" (slide 3) ...
> 
> "Additional Scripting Languages"
> 
> I guess we'll learn more the track but maybe it will incorporate 64-bit
> integers and all the associated changes that this would require (e.g. lexical
> functions overlaying system services).

The thought is that DCL will always be the command parser, and some other 
language (likely open source) would be used for scripting.

This issue isn't getting much focus by us yet, however.

-- 
                  -- Rob