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

[mcleanjoh at gmail.com]

On Friday, January 16, 2015 at 6:52:46 AM UTC+11, Bob Gezelter wrote:
> On Thursday, January 15, 2015 at 1:52:50 PM UTC-5, cme... at gmail.com wrote:
> > 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.
> 
> My comment about 0x7fff ffff is with regards to Hoff's comment about the work that was done to fix the signed/unsigned presumption. Earlier versions of OpenVMS were less fastidious in this regard, and my concern is breaking presently running code.
> 
> - Bob Gezelter, http://www.rlgsc.com

One option would be create a new set of prefix codes and routines so that people could move away from $GETDVI and DVI$_* codes and move to 64-bit alternative codes and routine if they wished to (eg. new $ GETDVI64 and DVI64$_*).

Users should of course be warned of the limitation of staying with the old codes and routines and be encouraged to move to the new.

Tinkering with the existing 32-bit stuff is likely to cause problems that the calling routines don't have provision for these newly introduced "enhancements" (e.g. a new error code for buffer overflow, a user defined input flag that says report sizes in MB).