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

[cmexec at gmail.com]

On Thursday, January 15, 2015 at 12:18:41 PM UTC-5, Bob Gezelter wrote:

> My point is that 0x7FFFFFFF is the largest unsigned number in the field (0xFFFFFFFF if all code is verified to use the number unsigned). VMS would then be guaranteeing that AT LEAST that amount is available. 

Yes, of course.  But it is also a valid correct answer, indistinguishable from "and maybe more".
If a volume did have exactly FFFFFFFE + 1 blocks, there would be no way for the software to know.

> You can believe it in the context that it is true, albeit potentially incomplete. For many programs, particularly those that are binary images using the existing API, that is likely enough.

I write software, not magic.  Either the answer is right or it is wrong.
 
> In any event, maxing the field is a safer bet than truncating the result. Maxing returns 0x7FFF FFFF in a longword. Truncating 0x80 0000 0000 yields 0x0, which is far more damaging.

7FFFFFFF is only the maximum if you are stuck with signed integers.  The VMS executive should not
be making up for limitations of a chosen implementation language.  Folks working in languages
that don't have unsigned are already used to the work needed to compensate for the language
limitation.  The executive should not cater to the needs of DCL, Fortran, ..., when the user could
choose to work in C, Macro-32, ..., or any other language that readily deals with unsigned.

Although I think I found a typo, truncating the result is consistent with the documented behavior.
I feel strongly that correcting the limitations of the existing behavior should not result in "maybe"
answers that imply my code can't be sure.