11.6.2.2125 REFILL FILE EXT
Extend the execution semantics of 6.2.2125 REFILL with the following:
When the input source is a text file, attempt to read the next line from the text-input file. If successful, make the result the current input buffer, set >IN to zero, and return true. Otherwise return false.
See:
ContributeContributions
ruv
[111] Ambiguous conditionsRequest for clarification2019-08-28 13:06:05
An excerpt from 11.3.3 Input source
A standard program shall not call
REPOSITION-FILEon the fileid returned bySOURCE-ID.
Is it correctly to say that an ambiguous condition exists if REPOSITION-FILE is applied to fileid returned by SOURCE-ID?
Shouldn't the Standard also say that a standard program shall not change the state of the input source via other words like WRITE-FILE, READ-FILE, READ-LINE, CLOSE-FILE, etc?
This question is connected with REFILL since the statement "attempt to read the next line from the text-input file" can create a wrong impression that READ-LINE may be applied to fileid from SOURCE-ID and REFILL should take the next line correctly after that.
AntonErtl
It's not specified as ambiguous condition, but the effect as far as standard programs are concerned is the same. As far as standard systems are concerned, the difference is that a system needs to document the result of an ambiguous condition (a pretty pointless exercise IMO).
Yes, I think that the file-id returned from SOURCE-ID should not be used for pretty much any file operation. I don't know of anybody who used SOURCE-ID for file operations, but absence of evidence is not evidence of absence.
It's unclear to me what the purpose of providing the file-id through SOURCE-ID was. It looks to me like a case where the committee had a specific implementation (line-at-a-time) in mind, and provided access to more implementation detail than actually needed. But if that was the case, why not also allow REPOSITION-FILE?
In any case, we may want to make the allowance to use other file words on the file-id returned by SOURCE-ID obsolescent.