[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference clt::dec_pascal_bugs

Title:DEC Pascal Bug Reports
Notice:New kit announcement in TURRIS::Pascal conference
Moderator:TLE::GARRISON
Created:Wed Sep 09 1992
Last Modified:Fri May 30 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:838
Total number of notes:3659

811.0. "Findk and unsigned16 key inconsistent" by CSC32::HADDOCK (Saddle Rozinante) Tue Nov 19 1996 14:43

T.RTitleUserPersonal
Name
DateLines
811.1TLE::REAGANAll of this chaos makes perfect senseWed Nov 20 1996 09:124
811.2CSC32::HADDOCKPas Fini!Mon Jan 27 1997 15:053
    
    Has anyone had a chance to look into this yet?
    fred();
811.3TLE::REAGANAll of this chaos makes perfect senseTue Jan 28 1997 10:537
    Nope.  Hadn't found anytime at all.  For those of you who haven't
    noticed, Steve Mailman (a Pascal developer for many, many years)
    has left the company.  Only myself and Meg Garrison are paddling
    all the platforms at the moment.  We hope to fill Steve's office, but 
    until then we appreciate your patience.
    
    				-John
811.4TLE::REAGANAll of this chaos makes perfect senseWed Feb 19 1997 13:3790
    OK, I finally looked at it.  Its a user-error (sorry it took so long
    just to say that).  The code checks UFB without first looking at the
    STATUS from FINDK.  If FINDK returns a non-zero status, UFB and EOF
    are undefined.  I'll admit that this isn't that obvious.  Section
    9.7 says to use STATUS to make sure any I/O routine called with
    ERROR := CONTINUE worked as expected.  The documentation for UFB
    could also be improved.  It currently says:
    
    "UFB returns FALSE if a *successful* (my emphasis) GET, FIND, FINDK,
    RESET, or RESETK operation has filled the file buffer.  GET, FIND,
    FINDK, RESET, and RESETK procedure calls that do not fill the file
    buffer set UFB to TRUE."
    
    The 2nd sentance should start with "Successful" as well to distinguish
    FINDKs that worked but didn't find the record in the file from FINDKs
    that were illegal due to other things and never even looked in the
    file.  We don't say (hence its undefined) about UFB after an unsuccessful
    call to FINDK ("unsuccessful" doesn't mean "we looked in the file and
    the record wasn't found", but rather "we couldn't even check the file to
    look for the record due to some error").  

    I'll make a note to change the manual next time around to better explain 
    the distiction between these two meanings of "unsuccessful".
    
    Here's a revised example to show the right way to do the checks:
    
program RMS_KEY_ERROR(output);
var
    f	: file of record
	uw_key:	[key(0)] unsigned16;
	end;
    uw	: unsigned16;
    


procedure try(ul	: unsigned);
begin
    writeln('Attempting to findk() ',ul:1,' in file...');    
    findk(f,0,ul,error := continue);
    if status(f) = 0 then
	{ FINDK was able to call RMS and see if the record really exists }
	if ufb(f) then
	    begin
	    writeln('  Findk() was unable to find the record');
	    writeln;
	    end
	else
	    begin
	    writeln('  Findk() was able to find the record');
	    writeln;
	    end
    else
	begin
	{ With a non-zero status, you cannot trust the value of }
	{ UFB or EOF.  With a non-zero status, the FINDK RTL    }
	{ routine may have not even called RMS at all.  It may  }
	{ have complained about the value not matching the key's}
	{ type (as in this example).  The buffer's contents are }
	{ still "valid" from the previous I/O operation.        }
	writeln('  Findk() has non-zero status of ',status(f):1,
                ' so UFB/EOF are undefined');
	writeln;
	end;

end; {of try()}


begin
    open(f,
	organization := indexed,
	access_method := keyed,
	record_type := fixed);

    writeln('Building temp file');
    for uw := 1 to 4 do
	begin
	f^.uw_key := uw;
	put(f);
	end;

    try(555555);
    try(666666);
    try(1);
    Try(555555);
    try(4);
    Try(555555);
end.