READ-FILE READ-LINE REPOSITION-FILE contain clauses stating an ambiguous condition exists if file is positioned outside the file boundaries.

AFAIK common practice in the real world is to allow file-positioning anywhere and let the subsequent read/write handle it - which in most cases won't return an error. Reading beyond end-of-file should return 0 bytes read and ior=0; writing beyond end-of-file is the basis of 'sparse' random access files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, May 18, 2023 at 4:53:20 AM UTC+2, dxforth wrote:

READ-FILE READ-LINE REPOSITION-FILE contain clauses stating an ambiguous condition exists if file is positioned outside the file boundaries.

AFAIK common practice in the real world is to allow file-positioning anywhere
and let the subsequent read/write handle it - which in most cases won't return
an error. Reading beyond end-of-file should return 0 bytes read and ior=0; writing beyond end-of-file is the basis of 'sparse' random access files.

I guess the ambiguity is because a 'file' can be any device, e.g., a keyboard, printer,
or a tape drive, or a paper tape ...

-marcel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

dxforth <[email protected]> writes:

READ-FILE READ-LINE REPOSITION-FILE contain clauses stating an ambiguous >condition exists if file is positioned outside the file boundaries.

AFAIK common practice in the real world is to allow file-positioning anywhere >and let the subsequent read/write handle it

What makes you think so? The first system I checked (Gforth on Linux)
behaves differently:

#200000. stdout reposition-file throw
*the terminal*:7:33: error: Illegal seek
#200000. stdout reposition-file >>>throw<<<

For a seekable file it seems that it indeed behaves as you describe:

[~/gforth:139436] echo >/tmp/xxx
[~/gforth:139437] gforth
...
s" /tmp/xxx" r/o open-file throw ok 1
constant xxx ok
#20000. xxx reposition-file throw ok
here 10 xxx read-file throw . 0 ok

In any case, given that all three words produce iors, an ambiguous
condition is not merited IMO. REPOSITION-FILE should either return a
non-zero ior, or a zero ior. Similarly, for READ-FILE and READ-LINE,
if the position is outside the written part of the file, they should
behave as you describe, or maybe return a non-zero ior (not sure if
there are any (operating or Forth) systems that need that). But who
is going to write the proposal?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marcel Hendrix <[email protected]> writes:

I guess the ambiguity is because a 'file' can be any device, e.g., a keyboa= >rd, printer,
or a tape drive, or a paper tape ...

"Everything is a file" is a Unixy way of seeing things; while this
approach has spread, it's not clear to me that it is universal. E.g.,
last I heard Windows still does not allow to access network
connections with fread() and fwrite().

And in Unix you then have files that are seekable and files that are
not; in particular, the Linux man page for fseek(3) and ftell(3) says:

|ERRORS
...
ESPIPE The file descriptor underlying stream is not seekable (e.g., it
refers to a pipe, FIFO, or socket).

and when I do in Gforth on Linux:

stdout file-position throw

I get

*the terminal*:2:22: error: Illegal seek
stdout file-position >>>throw<<<

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2022: https://euro.theforth.net

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 18/05/2023 6:25 pm, Anton Ertl wrote:

dxforth <[email protected]> writes:

READ-FILE READ-LINE REPOSITION-FILE contain clauses stating an ambiguous
condition exists if file is positioned outside the file boundaries.

AFAIK common practice in the real world is to allow file-positioning anywhere
and let the subsequent read/write handle it

What makes you think so? The first system I checked (Gforth on Linux) behaves differently:

#200000. stdout reposition-file throw
*the terminal*:7:33: error: Illegal seek
#200000. stdout reposition-file >>>throw<<<

For a seekable file it seems that it indeed behaves as you describe:

[~/gforth:139436] echo >/tmp/xxx
[~/gforth:139437] gforth
...
s" /tmp/xxx" r/o open-file throw ok 1
constant xxx ok
#20000. xxx reposition-file throw ok
here 10 xxx read-file throw . 0 ok

In any case, given that all three words produce iors, an ambiguous
condition is not merited IMO. REPOSITION-FILE should either return a non-zero ior, or a zero ior. Similarly, for READ-FILE and READ-LINE,
if the position is outside the written part of the file, they should
behave as you describe, or maybe return a non-zero ior (not sure if
there are any (operating or Forth) systems that need that). But who
is going to write the proposal?

Can't speak to that. All I know is coding to the OS file spec was easier
than coding to ANS.

https://pastebin.com/ckAVESxA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)