[Info-vax] Looking for suggestions for new $GETDVI item codes

[Stephen Hoffman]

On 2015-01-15 17:18:40 +0000, Bob Gezelter said:

> On Thursday, January 15, 2015 at 11:53:16 AM UTC-5, cme... at gmail.com wrote:
>> On Thursday, January 15, 2015 at 9:23:55 AM UTC-5, Bob Gezelter wrote:
>> 
>> ...
>> I very much disagree with that approach.  If VMS tells me something is 
>> FFFFFFFF blocks, I want to be able to believe it.
>> 
> My point is that 0x7FFFFFFF is the largest unsigned number in the field 
> (0xFFFFFFFF if all code is verified to use the number unsigned).

2 TiB is the V8.4 limit, and the VMS code was tested for unsigned, 
modulo the DCL handling.

> Maxing is not a cure-all, it is merely a more constructive response to 
> back compatibility.

Maxing out the value has been done in the lock manager, but it's an 
expedient hack, and such hacks almost inevitably cause problems later.  
In the case of the volume size, quite possibly because somebody 
eventually encounters a disk volume of that size and runs into weird 
behavior, or because there's now a disjoint range of values that makes 
for ugly and arcane and failure-prone application code (there's 
effectively now a third place to look for a return status value from 
$getdvi[w]), or because some unwary programmer somewhere messed up the 
handling of the magic value when they added support for 64-bit support 
(as C signed and unsigned integer promotion rules have messed up more 
than a few folks, after all).

If the value doesn't fit, return an error via the IOSB.  Let the 
application programmer sort out the error, or remove the volume that's 
larger than 2 TiB.


-- 
Pure Personal Opinion | HoffmanLabs LLC