CBFalconer wrote:
Emil Jerabek wrote:
... snip ...
Sorry, should think twice before submitting a bugreport. The story with "file of record end" is more complicated then I wrote.
The test below should pass for any type (which is permissible as a file component-type, of course). It indeed works with, say, "file of Integer", but with the empty record type it fails:
[...]
I have not checked the standards, but is the problem accepting the empty record? It seems like a pointless thing to do, leading to all sorts of problems, such as:
Sure, it is completely pointless, except that it _is_ mandated by the standard. Namely, section 6.4.3.4 (Record-types) of ISO 10206 says:
...
record-type = `record' field-list `end' .
field-list = [ ( fixed-part [ `;' variant-part ] | variant-part ) [ `;' ] ] .
...
A field-list containing neither a fixed-part nor a variant-part shall have no components, shall determine a single value-bearing state bearing a null value, shall be designated empty, and shall denote the totally-undefined initial state.
...
TYPE per = ^emptyrecord; VAR erarray : ARRAY[1..N] OF emptyrecord;
... new(per); erarray[i] := erarray[j]; erarray[i] := per^; per^ := erarray[i]; dispose(per);
Well, what's the problem here? All these assignment statements are simply no-ops.
etc. Accepting that has further problems with the design of the memory allocation mechanism - I have just built one for DJGPP and had to detect a zero size and increment it, otherwise storage needed for free block tracking would have been missing. The ramifications of an empty object go on and on and on and ....
-- Chuck F (cbfalconer@yahoo.com) (cbfalconer@XXXXworldnet.att.net) Available for consulting/temporary embedded and systems. (Remove "XXXX" from reply address. yahoo works unmodified) mailto:uce@ftc.gov (for spambots to harvest)
Emil Jerabek