The recent discussions about throw codes and iors have inspired me to
look at what various systems do.

I feed the following to each system:

s" /bla" r/w create-file dup . throw
s" /blub/bla" r/w create-file dup . throw

I run this as a user who is not allowed to write into the directory /;
there is also no directory /blub.

Gforth 0.7.9_20211216
s" /bla" r/w create-file dup . throw -525
*the terminal*:1:32: error: Permission denied
s" /bla" r/w create-file dup . >>>throw<<<
s" /blub/bla" r/w create-file dup . throw -514
*the terminal*:2:37: error: No such file or directory
s" /blub/bla" r/w create-file dup . >>>throw<<<

Gforth calls an OS function for creating the file, and the OS (Linux)
reports different errors for these two cases: EACCESS (13) for the first
case, because the user is not allowed to write to /; ENOENT (2) for the
second case, because there is not directory /blub to write to.

Gforth transforms the OS error numbers (1 and up) into the range of
Forth system-defined throw codes (-512 and less; Gforth uses
-511..-256 for signals), and returns it as ior. The user code than
throws that ior, which is then caught by the system exception handler,
which transforms the error number back to the OS error number, and
uses strerror() to get a string for the error, and prints it.

VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64

s" /bla" r/w create-file dup . throw -63
Err# -63 ERR: from CREATE-FILE
-> s" /bla" r/w create-file dup . throw
^
s" /blub/bla" r/w create-file dup . throw -63
Err# -63 ERR: from CREATE-FILE
-> s" /blub/bla" r/w create-file dup . throw
^

VFX notices that there is an error condition, and returns the ior -63
(CREATE-FILE) in either case. The system exception handler knows the
proper string for this exception.

SwiftForth i386-Linux 3.11.0 23-Feb-2021
s" /bla" r/w create-file dup . throw -198 Can't create file
s" /blub/bla" r/w create-file dup . throw -198 Can't create file

This is essentially the same approach as used by VFX, but it uses
an ior that's not defined as throw code by the standard, but is in the
range of throw codes reserved for definition by the standard
(-255..-1).

iforth-5.1 mini:
FORTH> s" /bla" r/w create-file dup . throw 13
Error 13 ?
FORTH> s" /blub/bla" r/w create-file dup . throw 2
Error 2 ?

iForth apparently returns the OS error number without transforming it
into the range of system-defined throw codes (-4095..-256). The
system's catch handler does not know how to print a useful string for
it. However, maybe my iForth setup is at fault.

lxf Version 1.6-982-823 Compiled on 2017-12-03
s" /bla" r/w create-file dup . throw -63
terminal col: 36
create-file error at 088D0D47

s" /blub/bla" r/w create-file dup . throw -63
terminal col: 41
create-file error at 088D0D47

This is essentially the same approach as used by VFX.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Anton Ertl schrieb am Freitag, 7. Januar 2022 um 14:07:28 UTC+1:
> The recent discussions about throw codes and iors have inspired me to
> look at what various systems do.
>
> I feed the following to each system:
>
> s" /bla" r/w create-file dup . throw
> s" /blub/bla" r/w create-file dup . throw
>
> I run this as a user who is not allowed to write into the directory /;
> there is also no directory /blub.
>
> Gforth 0.7.9_20211216
> s" /bla" r/w create-file dup . throw -525
> *the terminal*:1:32: error: Permission denied
> s" /bla" r/w create-file dup . >>>throw<<<
> s" /blub/bla" r/w create-file dup . throw -514
> *the terminal*:2:37: error: No such file or directory
> s" /blub/bla" r/w create-file dup . >>>throw<<<
>
> Gforth calls an OS function for creating the file, and the OS (Linux)
> reports different errors for these two cases: EACCESS (13) for the first
> case, because the user is not allowed to write to /; ENOENT (2) for the
> second case, because there is not directory /blub to write to.
>
> Gforth transforms the OS error numbers (1 and up) into the range of
> Forth system-defined throw codes (-512 and less; Gforth uses
> -511..-256 for signals), and returns it as ior. The user code than
> throws that ior, which is then caught by the system exception handler,
> which transforms the error number back to the OS error number, and
> uses strerror() to get a string for the error, and prints it.
>
>
> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>
> s" /bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /bla" r/w create-file dup . throw
> ^
> s" /blub/bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /blub/bla" r/w create-file dup . throw
> ^
>
> VFX notices that there is an error condition, and returns the ior -63
> (CREATE-FILE) in either case. The system exception handler knows the
> proper string for this exception.
>
>
> SwiftForth i386-Linux 3.11.0 23-Feb-2021
> s" /bla" r/w create-file dup . throw -198 Can't create file
> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
>
> This is essentially the same approach as used by VFX, but it uses
> an ior that's not defined as throw code by the standard, but is in the
> range of throw codes reserved for definition by the standard
> (-255..-1).
>
>
> iforth-5.1 mini:
> FORTH> s" /bla" r/w create-file dup . throw 13
> Error 13 ?
> FORTH> s" /blub/bla" r/w create-file dup . throw 2
> Error 2 ?
>
> iForth apparently returns the OS error number without transforming it
> into the range of system-defined throw codes (-4095..-256). The
> system's catch handler does not know how to print a useful string for
> it. However, maybe my iForth setup is at fault.
>
>
> lxf Version 1.6-982-823 Compiled on 2017-12-03
> s" /bla" r/w create-file dup . throw -63
> terminal col: 36
> create-file error at 088D0D47
>
> s" /blub/bla" r/w create-file dup . throw -63
> terminal col: 41
> create-file error at 088D0D47
>
> This is essentially the same approach as used by VFX.
>

Forth94 did not yet declare throw codes -62...-76 for file access words.
So gforth seems a bit retarded here.

On 1/7/22 05:52, Anton Ertl wrote:
> The recent discussions about throw codes and iors have inspired me to
> look at what various systems do.
>
> I feed the following to each system:
>
> s" /bla" r/w create-file dup . throw
> s" /blub/bla" r/w create-file dup . throw
>
> I run this as a user who is not allowed to write into the directory /;
> there is also no directory /blub.
>
> Gforth 0.7.9_20211216
> s" /bla" r/w create-file dup . throw -525
> *the terminal*:1:32: error: Permission denied
> s" /bla" r/w create-file dup . >>>throw<<<
> s" /blub/bla" r/w create-file dup . throw -514
> *the terminal*:2:37: error: No such file or directory
> s" /blub/bla" r/w create-file dup . >>>throw<<<
>
> Gforth calls an OS function for creating the file, and the OS (Linux)
> reports different errors for these two cases: EACCESS (13) for the first
> case, because the user is not allowed to write to /; ENOENT (2) for the
> second case, because there is not directory /blub to write to.
>
> Gforth transforms the OS error numbers (1 and up) into the range of
> Forth system-defined throw codes (-512 and less; Gforth uses
> -511..-256 for signals), and returns it as ior. The user code than
> throws that ior, which is then caught by the system exception handler,
> which transforms the error number back to the OS error number, and
> uses strerror() to get a string for the error, and prints it.
>
>
> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>
> s" /bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /bla" r/w create-file dup . throw
> ^
> s" /blub/bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /blub/bla" r/w create-file dup . throw
> ^
>
> VFX notices that there is an error condition, and returns the ior -63
> (CREATE-FILE) in either case. The system exception handler knows the
> proper string for this exception.
>
>
> SwiftForth i386-Linux 3.11.0 23-Feb-2021
> s" /bla" r/w create-file dup . throw -198 Can't create file
> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
>
> This is essentially the same approach as used by VFX, but it uses
> an ior that's not defined as throw code by the standard, but is in the
> range of throw codes reserved for definition by the standard
> (-255..-1).
>
>
> iforth-5.1 mini:
> FORTH> s" /bla" r/w create-file dup . throw 13
> Error 13 ?
> FORTH> s" /blub/bla" r/w create-file dup . throw 2
> Error 2 ?
>
> iForth apparently returns the OS error number without transforming it
> into the range of system-defined throw codes (-4095..-256). The
> system's catch handler does not know how to print a useful string for
> it. However, maybe my iForth setup is at fault.
>
>
> lxf Version 1.6-982-823 Compiled on 2017-12-03
> s" /bla" r/w create-file dup . throw -63
> terminal col: 36
> create-file error at 088D0D47
>
> s" /blub/bla" r/w create-file dup . throw -63
> terminal col: 41
> create-file error at 088D0D47
>
> This is essentially the same approach as used by VFX.
>
> - anton
>

In kForth, the standard file access words are implemented in Forth
source (files.4th) using lower-level OS calls. The OS calls return the
OS error code; however, the standard file access words translate these
into simply a 0 or -1 as the ior. The only word which returns the OS
error code for ior is CLOSE-FILE. Hence, both of your examples currently
return -1 in kForth.

\ requires ans-words.4th, strings.4th, files.4th

s" /bla" r/w create-file dup . throw
-1 Line 308: VM Error(-1):
s" /bla" r/w create-file dup . throw
ok

s" /blub/bla" r/w create-file dup . throw
-1 Line 311: VM Error(-1):
s" /blub/bla" r/w create-file dup . throw

Since the file access words are in source, it is easy to make the ior
values consistent with throw codes from Table 9.1 of the Forth-2012
standard. Thus changing the definition of CREATE-FILE from files.4th to

\ CREATE-FILE ( c-addr u fam -- fileid ior )
\ Create a file with the specified name.
\ Forth-94/2012 File Access word set 11.6.1.1010
: create-file
>r strpck r> O_CREAT or open
\ dup 0> invert ;
dup 0< if -63 else 0 then ;

the following behavior results (with the most recent master branches of
kForth-64 and kForth-32).

s" /bla" r/w create-file dup . throw
-63 Line 4: VM Error(-63): CREATE-FILE
s" /bla" r/w create-file dup . throw
ok
ok
s" /blub/bla" r/w create-file dup . throw
-63 Line 5: VM Error(-63): CREATE-FILE
s" /blub/bla" r/w create-file dup . throw

I will have to examine the affect of changing the ior codes on existing
source before making changes the release version of files.4th to be
consistent with Forth 2012; apparently, there was some confusion about
this among system implementors. In any case, it is clear that the file
access words themselves were not to execute the throw.

Krishna

On 1/7/22 07:40, minf...@arcor.de wrote:
> Anton Ertl schrieb am Freitag, 7. Januar 2022 um 14:07:28 UTC+1:
>> The recent discussions about throw codes and iors have inspired me to
>> look at what various systems do.
>>
>> I feed the following to each system:
>>
>> s" /bla" r/w create-file dup . throw
>> s" /blub/bla" r/w create-file dup . throw
>>
>> I run this as a user who is not allowed to write into the directory /;
>> there is also no directory /blub.
>>
>> Gforth 0.7.9_20211216
>> s" /bla" r/w create-file dup . throw -525
>> *the terminal*:1:32: error: Permission denied
>> s" /bla" r/w create-file dup . >>>throw<<<
>> s" /blub/bla" r/w create-file dup . throw -514
>> *the terminal*:2:37: error: No such file or directory
>> s" /blub/bla" r/w create-file dup . >>>throw<<<
>>
>> Gforth calls an OS function for creating the file, and the OS (Linux)
>> reports different errors for these two cases: EACCESS (13) for the first
>> case, because the user is not allowed to write to /; ENOENT (2) for the
>> second case, because there is not directory /blub to write to.
>>
>> Gforth transforms the OS error numbers (1 and up) into the range of
>> Forth system-defined throw codes (-512 and less; Gforth uses
>> -511..-256 for signals), and returns it as ior. The user code than
>> throws that ior, which is then caught by the system exception handler,
>> which transforms the error number back to the OS error number, and
>> uses strerror() to get a string for the error, and prints it.
>>
>>
>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>>
>> s" /bla" r/w create-file dup . throw -63
>> Err# -63 ERR: from CREATE-FILE
>> -> s" /bla" r/w create-file dup . throw
>> ^
>> s" /blub/bla" r/w create-file dup . throw -63
>> Err# -63 ERR: from CREATE-FILE
>> -> s" /blub/bla" r/w create-file dup . throw
>> ^
>>
>> VFX notices that there is an error condition, and returns the ior -63
>> (CREATE-FILE) in either case. The system exception handler knows the
>> proper string for this exception.
>>
>>
>> SwiftForth i386-Linux 3.11.0 23-Feb-2021
>> s" /bla" r/w create-file dup . throw -198 Can't create file
>> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
>>
>> This is essentially the same approach as used by VFX, but it uses
>> an ior that's not defined as throw code by the standard, but is in the
>> range of throw codes reserved for definition by the standard
>> (-255..-1).
>>
>>
>> iforth-5.1 mini:
>> FORTH> s" /bla" r/w create-file dup . throw 13
>> Error 13 ?
>> FORTH> s" /blub/bla" r/w create-file dup . throw 2
>> Error 2 ?
>>
>> iForth apparently returns the OS error number without transforming it
>> into the range of system-defined throw codes (-4095..-256). The
>> system's catch handler does not know how to print a useful string for
>> it. However, maybe my iForth setup is at fault.
>>
>>
>> lxf Version 1.6-982-823 Compiled on 2017-12-03
>> s" /bla" r/w create-file dup . throw -63
>> terminal col: 36
>> create-file error at 088D0D47
>>
>> s" /blub/bla" r/w create-file dup . throw -63
>> terminal col: 41
>> create-file error at 088D0D47
>>
>> This is essentially the same approach as used by VFX.
>>
>
> Forth94 did not yet declare throw codes -62...-76 for file access words.
> So gforth seems a bit retarded here.
>

Actually, Gforth is providing more precise information about the type of
error rather than returning -63 for both cases. The Gforth ior (and the
iForth ior) are more useful; however, it is also useful if the ior(s)
could be made consistent for improved portability of source code. Since
the Forth-2012 standard provides a range for system-defined throw codes,
Gforth's output is currently consistent with the standard, though it is
not clear whether or not the intent in Forth-2012 was to standardize the
ior(s) for the file access words.

--
Krishna

Krishna Myneni schrieb am Freitag, 7. Januar 2022 um 17:02:09 UTC+1:
> On 1/7/22 07:40, minf...@arcor.de wrote:
> > Anton Ertl schrieb am Freitag, 7. Januar 2022 um 14:07:28 UTC+1:
> >> The recent discussions about throw codes and iors have inspired me to
> >> look at what various systems do.
> >>
> >> I feed the following to each system:
> >>
> >> s" /bla" r/w create-file dup . throw
> >> s" /blub/bla" r/w create-file dup . throw
> >>
> >> I run this as a user who is not allowed to write into the directory /;
> >> there is also no directory /blub.
> >>
> >> Gforth 0.7.9_20211216
> >> s" /bla" r/w create-file dup . throw -525
> >> *the terminal*:1:32: error: Permission denied
> >> s" /bla" r/w create-file dup . >>>throw<<<
> >> s" /blub/bla" r/w create-file dup . throw -514
> >> *the terminal*:2:37: error: No such file or directory
> >> s" /blub/bla" r/w create-file dup . >>>throw<<<
> >>
> >> Gforth calls an OS function for creating the file, and the OS (Linux)
> >> reports different errors for these two cases: EACCESS (13) for the first
> >> case, because the user is not allowed to write to /; ENOENT (2) for the
> >> second case, because there is not directory /blub to write to.
> >>
> >> Gforth transforms the OS error numbers (1 and up) into the range of
> >> Forth system-defined throw codes (-512 and less; Gforth uses
> >> -511..-256 for signals), and returns it as ior. The user code than
> >> throws that ior, which is then caught by the system exception handler,
> >> which transforms the error number back to the OS error number, and
> >> uses strerror() to get a string for the error, and prints it.
> >>
> >>
> >> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
> >>
> >> s" /bla" r/w create-file dup . throw -63
> >> Err# -63 ERR: from CREATE-FILE
> >> -> s" /bla" r/w create-file dup . throw
> >> ^
> >> s" /blub/bla" r/w create-file dup . throw -63
> >> Err# -63 ERR: from CREATE-FILE
> >> -> s" /blub/bla" r/w create-file dup . throw
> >> ^
> >>
> >> VFX notices that there is an error condition, and returns the ior -63
> >> (CREATE-FILE) in either case. The system exception handler knows the
> >> proper string for this exception.
> >>
> >>
> >> SwiftForth i386-Linux 3.11.0 23-Feb-2021
> >> s" /bla" r/w create-file dup . throw -198 Can't create file
> >> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
> >>
> >> This is essentially the same approach as used by VFX, but it uses
> >> an ior that's not defined as throw code by the standard, but is in the
> >> range of throw codes reserved for definition by the standard
> >> (-255..-1).
> >>
> >>
> >> iforth-5.1 mini:
> >> FORTH> s" /bla" r/w create-file dup . throw 13
> >> Error 13 ?
> >> FORTH> s" /blub/bla" r/w create-file dup . throw 2
> >> Error 2 ?
> >>
> >> iForth apparently returns the OS error number without transforming it
> >> into the range of system-defined throw codes (-4095..-256). The
> >> system's catch handler does not know how to print a useful string for
> >> it. However, maybe my iForth setup is at fault.
> >>
> >>
> >> lxf Version 1.6-982-823 Compiled on 2017-12-03
> >> s" /bla" r/w create-file dup . throw -63
> >> terminal col: 36
> >> create-file error at 088D0D47
> >>
> >> s" /blub/bla" r/w create-file dup . throw -63
> >> terminal col: 41
> >> create-file error at 088D0D47
> >>
> >> This is essentially the same approach as used by VFX.
> >>
> >
> > Forth94 did not yet declare throw codes -62...-76 for file access words.
> > So gforth seems a bit retarded here.
> >
> Actually, Gforth is providing more precise information about the type of
> error rather than returning -63 for both cases. The Gforth ior (and the
> iForth ior) are more useful; however, it is also useful if the ior(s)
> could be made consistent for improved portability of source code. Since
> the Forth-2012 standard provides a range for system-defined throw codes,
> Gforth's output is currently consistent with the standard, though it is
> not clear whether or not the intent in Forth-2012 was to standardize the
> ior(s) for the file access words.
>

Side remark: C errno's are no standardizedized integers, but resolved symbolic
via header file errno.h. Forth ior's are not standardized at all. Whether one can
decypher more error information from errno or ior values is compiler-specific.

On 07.01.2022 17:18, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Freitag, 7. Januar 2022 um 17:02:09 UTC+1:

>> Actually, Gforth is providing more precise information about the type of
>> error rather than returning -63 for both cases. The Gforth ior (and the
>> iForth ior) are more useful; however, it is also useful if the ior(s)
>> could be made consistent for improved portability of source code. Since
>> the Forth-2012 standard provides a range for system-defined throw codes,
>> Gforth's output is currently consistent with the standard, though it is
>> not clear whether or not the intent in Forth-2012 was to standardize the
>> ior(s) for the file access words.
>>
>
> Side remark: C errno's are no standardizedized integers, but resolved
symbolic
> via header file errno.h. Forth ior's are not standardized at all.
Whether one can
> decypher more error information from errno or ior values is
compiler-specific.
The opposite is true: glibc errno codes are standardized in IEEE Std.
1003 (widely known as POSIX).

Regards,
--
Bernd

On Friday, January 7, 2022 at 7:32:49 PM UTC+3, Bernd Linsel wrote:
> On 07.01.2022 17:18, minf...@arcor.de wrote:
> > Krishna Myneni schrieb am Freitag, 7. Januar 2022 um 17:02:09 UTC+1:
>
> >> Actually, Gforth is providing more precise information about the type of
> >> error rather than returning -63 for both cases. The Gforth ior (and the
> >> iForth ior) are more useful; however, it is also useful if the ior(s)
> >> could be made consistent for improved portability of source code. Since
> >> the Forth-2012 standard provides a range for system-defined throw codes,
> >> Gforth's output is currently consistent with the standard, though it is
> >> not clear whether or not the intent in Forth-2012 was to standardize the
> >> ior(s) for the file access words.
> >>
> >
> > Side remark: C errno's are no standardizedized integers, but resolved
> symbolic
> > via header file errno.h. Forth ior's are not standardized at all.
> Whether one can
> > decypher more error information from errno or ior values is
> compiler-specific.
> The opposite is true: glibc errno codes are standardized in IEEE Std.
> 1003 (widely known as POSIX).
>

AFAIK, names, not values.

On 1/7/22 10:18, minf...@arcor.de wrote:
> Krishna Myneni schrieb am Freitag, 7. Januar 2022 um 17:02:09 UTC+1:
>> On 1/7/22 07:40, minf...@arcor.de wrote:
>>> Anton Ertl schrieb am Freitag, 7. Januar 2022 um 14:07:28 UTC+1:
>>>> The recent discussions about throw codes and iors have inspired me to
>>>> look at what various systems do.
>>>>
>>>> I feed the following to each system:
>>>>
>>>> s" /bla" r/w create-file dup . throw
>>>> s" /blub/bla" r/w create-file dup . throw
>>>>
>>>> I run this as a user who is not allowed to write into the directory /;
>>>> there is also no directory /blub.
>>>>
>>>> Gforth 0.7.9_20211216
>>>> s" /bla" r/w create-file dup . throw -525
>>>> *the terminal*:1:32: error: Permission denied
>>>> s" /bla" r/w create-file dup . >>>throw<<<
>>>> s" /blub/bla" r/w create-file dup . throw -514
>>>> *the terminal*:2:37: error: No such file or directory
>>>> s" /blub/bla" r/w create-file dup . >>>throw<<<
>>>>
>>>> Gforth calls an OS function for creating the file, and the OS (Linux)
>>>> reports different errors for these two cases: EACCESS (13) for the first
>>>> case, because the user is not allowed to write to /; ENOENT (2) for the
>>>> second case, because there is not directory /blub to write to.
>>>>
>>>> Gforth transforms the OS error numbers (1 and up) into the range of
>>>> Forth system-defined throw codes (-512 and less; Gforth uses
>>>> -511..-256 for signals), and returns it as ior. The user code than
>>>> throws that ior, which is then caught by the system exception handler,
>>>> which transforms the error number back to the OS error number, and
>>>> uses strerror() to get a string for the error, and prints it.
>>>>
>>>>
>>>> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>>>>
>>>> s" /bla" r/w create-file dup . throw -63
>>>> Err# -63 ERR: from CREATE-FILE
>>>> -> s" /bla" r/w create-file dup . throw
>>>> ^
>>>> s" /blub/bla" r/w create-file dup . throw -63
>>>> Err# -63 ERR: from CREATE-FILE
>>>> -> s" /blub/bla" r/w create-file dup . throw
>>>> ^
>>>>
>>>> VFX notices that there is an error condition, and returns the ior -63
>>>> (CREATE-FILE) in either case. The system exception handler knows the
>>>> proper string for this exception.
>>>>
>>>>
>>>> SwiftForth i386-Linux 3.11.0 23-Feb-2021
>>>> s" /bla" r/w create-file dup . throw -198 Can't create file
>>>> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
>>>>
>>>> This is essentially the same approach as used by VFX, but it uses
>>>> an ior that's not defined as throw code by the standard, but is in the
>>>> range of throw codes reserved for definition by the standard
>>>> (-255..-1).
>>>>
>>>>
>>>> iforth-5.1 mini:
>>>> FORTH> s" /bla" r/w create-file dup . throw 13
>>>> Error 13 ?
>>>> FORTH> s" /blub/bla" r/w create-file dup . throw 2
>>>> Error 2 ?
>>>>
>>>> iForth apparently returns the OS error number without transforming it
>>>> into the range of system-defined throw codes (-4095..-256). The
>>>> system's catch handler does not know how to print a useful string for
>>>> it. However, maybe my iForth setup is at fault.
>>>>
>>>>
>>>> lxf Version 1.6-982-823 Compiled on 2017-12-03
>>>> s" /bla" r/w create-file dup . throw -63
>>>> terminal col: 36
>>>> create-file error at 088D0D47
>>>>
>>>> s" /blub/bla" r/w create-file dup . throw -63
>>>> terminal col: 41
>>>> create-file error at 088D0D47
>>>>
>>>> This is essentially the same approach as used by VFX.
>>>>
>>>
>>> Forth94 did not yet declare throw codes -62...-76 for file access words.
>>> So gforth seems a bit retarded here.
>>>
>> Actually, Gforth is providing more precise information about the type of
>> error rather than returning -63 for both cases. The Gforth ior (and the
>> iForth ior) are more useful; however, it is also useful if the ior(s)
>> could be made consistent for improved portability of source code. Since
>> the Forth-2012 standard provides a range for system-defined throw codes,
>> Gforth's output is currently consistent with the standard, though it is
>> not clear whether or not the intent in Forth-2012 was to standardize the
>> ior(s) for the file access words.
>>
>
> Side remark: C errno's are no standardizedized integers, but resolved symbolic
> via header file errno.h. Forth ior's are not standardized at all. Whether one can
> decypher more error information from errno or ior values is compiler-specific.
>

One way to use standard symbolic names for ior(s) in Forth is to have a
separate wordlist in the Forth system, with named constants and
association pairs between the ior constant names and strings to inform
the user of the nature of the error. Then, Table 9.1 need only specify
the names of the constants for the associated error (and not the
constants themselves). Upon obtaining an ior, the program can compare
against the symbolic names, or even lookup the symbolic name for a given
number, using TRAVERSE-WORDLIST, and also find the associated string.

--
Krishna

"minf...@arcor.de" <minforth@arcor.de> writes:
>Anton Ertl schrieb am Freitag, 7. Januar 2022 um 14:07:28 UTC+1:
>> The recent discussions about throw codes and iors have inspired me to
>> look at what various systems do.
>>
>> I feed the following to each system:
>>
>> s" /bla" r/w create-file dup . throw
>> s" /blub/bla" r/w create-file dup . throw
>>
>> I run this as a user who is not allowed to write into the directory /;
>> there is also no directory /blub.
>>
>> Gforth 0.7.9_20211216
>> s" /bla" r/w create-file dup . throw -525
>> *the terminal*:1:32: error: Permission denied
>> s" /bla" r/w create-file dup . >>>throw<<<
>> s" /blub/bla" r/w create-file dup . throw -514
>> *the terminal*:2:37: error: No such file or directory
>> s" /blub/bla" r/w create-file dup . >>>throw<<<
>>
>> Gforth calls an OS function for creating the file, and the OS (Linux)
>> reports different errors for these two cases: EACCESS (13) for the first
>> case, because the user is not allowed to write to /; ENOENT (2) for the
>> second case, because there is not directory /blub to write to.
>>
>> Gforth transforms the OS error numbers (1 and up) into the range of
>> Forth system-defined throw codes (-512 and less; Gforth uses
>> -511..-256 for signals), and returns it as ior. The user code than
>> throws that ior, which is then caught by the system exception handler,
>> which transforms the error number back to the OS error number, and
>> uses strerror() to get a string for the error, and prints it.
....
>Forth94 did not yet declare throw codes -62...-76 for file access words.
>So gforth seems a bit retarded here.

I think that Gforth is advanced, because it provides more useful
information than just what word had a non-zero ior. That's also why I
think that the throw codes <-58 (except -77) are useless. We have no
intention of dumbing down Gforth to the level of VFX.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Krishna Myneni <krishna.myneni@ccreweb.org> writes:
>however, it is also useful if the ior(s)
>could be made consistent for improved portability of source code.

Actually for the way I have used THROW and CATCH, I have not needed to
make the iors of OS errors explicit yet; the values come out of the
OS/libc are transformed forth and back, and passed back into the libc
for conversion into a string.

But sure, there can be cases for which it can be useful to check the
error code at the Forth level, and for that I would suggest to supply
Forth words for (transformed) POSIX errno values. But given the lack
of common practice, I don't expect that this would be standardizable
soon.

>it is
>not clear whether or not the intent in Forth-2012 was to standardize the
>ior(s) for the file access words.

It was certainly not my intent when I agreed with
<http://www.forth200x.org/throw-iors.html> to require, e.g.,
CREATE-FILE to only ever return 0 or -63. And the standard certainly
contains no wording in that direction; I would have voted against such
a proposal.

Looking at <http://www.forth200x.org/throw-iors.html#comments>:

Stephen Pelc points out that the proposal does not say that you must
use these throw numbers, it says that if you use these numbers, this
is what the standard means by those specific numbers. Consequently
gForth will not conflict with 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Anton Ertl schrieb am Freitag, 7. Januar 2022 um 19:08:54 UTC+1:
> Krishna Myneni <krishna...@ccreweb.org> writes:
> >however, it is also useful if the ior(s)
> >could be made consistent for improved portability of source code.
> Actually for the way I have used THROW and CATCH, I have not needed to
> make the iors of OS errors explicit yet; the values come out of the
> OS/libc are transformed forth and back, and passed back into the libc
> for conversion into a string.
>
> But sure, there can be cases for which it can be useful to check the
> error code at the Forth level, and for that I would suggest to supply
> Forth words for (transformed) POSIX errno values. But given the lack
> of common practice, I don't expect that this would be standardizable
> soon.
> >it is
> >not clear whether or not the intent in Forth-2012 was to standardize the
> >ior(s) for the file access words.
> It was certainly not my intent when I agreed with
> <http://www.forth200x.org/throw-iors.html> to require, e.g.,
> CREATE-FILE to only ever return 0 or -63. And the standard certainly
> contains no wording in that direction; I would have voted against such
> a proposal.
>
> Looking at <http://www.forth200x.org/throw-iors.html#comments>:
>
> Stephen Pelc points out that the proposal does not say that you must
> use these throw numbers, it says that if you use these numbers, this
> is what the standard means by those specific numbers. Consequently
> gForth will not conflict with the proposal.

When even the oh-so-very-compliant Forths all cook their own dialect,
things can only get better. ;-)

On 2022-01-07 14:52, Anton Ertl wrote:
> The recent discussions about throw codes and iors have inspired me to
> look at what various systems do.
>
> I feed the following to each system:
>
> s" /bla" r/w create-file dup . throw
> s" /blub/bla" r/w create-file dup . throw
>
> I run this as a user who is not allowed to write into the directory /;
> there is also no directory /blub.
>
> Gforth 0.7.9_20211216
> s" /bla" r/w create-file dup . throw -525
> *the terminal*:1:32: error: Permission denied
> s" /bla" r/w create-file dup . >>>throw<<<
> s" /blub/bla" r/w create-file dup . throw -514
> *the terminal*:2:37: error: No such file or directory
> s" /blub/bla" r/w create-file dup . >>>throw<<<
>
> Gforth calls an OS function for creating the file, and the OS (Linux)
> reports different errors for these two cases: EACCESS (13) for the first
> case, because the user is not allowed to write to /; ENOENT (2) for the
> second case, because there is not directory /blub to write to.
>
> Gforth transforms the OS error numbers (1 and up) into the range of
> Forth system-defined throw codes (-512 and less; Gforth uses
> -511..-256 for signals), and returns it as ior. The user code than
> throws that ior, which is then caught by the system exception handler,
> which transforms the error number back to the OS error number, and
> uses strerror() to get a string for the error, and prints it.
>
>
> VFX Forth 64 5.11 RC2 [build 0112] 2021-05-02 for Linux x64
>
> s" /bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /bla" r/w create-file dup . throw
> ^
> s" /blub/bla" r/w create-file dup . throw -63
> Err# -63 ERR: from CREATE-FILE
> -> s" /blub/bla" r/w create-file dup . throw
> ^
>
> VFX notices that there is an error condition, and returns the ior -63
> (CREATE-FILE) in either case. The system exception handler knows the
> proper string for this exception.
>
>
> SwiftForth i386-Linux 3.11.0 23-Feb-2021
> s" /bla" r/w create-file dup . throw -198 Can't create file
> s" /blub/bla" r/w create-file dup . throw -198 Can't create file
>
> This is essentially the same approach as used by VFX, but it uses
> an ior that's not defined as throw code by the standard, but is in the
> range of throw codes reserved for definition by the standard
> (-255..-1).
>
>
> iforth-5.1 mini:
> FORTH> s" /bla" r/w create-file dup . throw 13
> Error 13 ?
> FORTH> s" /blub/bla" r/w create-file dup . throw 2
> Error 2 ?
>
> iForth apparently returns the OS error number without transforming it
> into the range of system-defined throw codes (-4095..-256). The
> system's catch handler does not know how to print a useful string for
> it. However, maybe my iForth setup is at fault.
>
>
> lxf Version 1.6-982-823 Compiled on 2017-12-03
> s" /bla" r/w create-file dup . throw -63
> terminal col: 36
> create-file error at 088D0D47
>
> s" /blub/bla" r/w create-file dup . throw -63
> terminal col: 41
> create-file error at 088D0D47
>
> This is essentially the same approach as used by VFX.
>

SP-Forth/4.21 for Windows

s" /bla" r/w create-file dup . cr throw
5 s" /bla r/w create-file dup . cr throw
^ 5 ERROR_ACCESS_DENIED

s" /blub/bla" r/w create-file dup . cr throw
3 s" /blub/bla r/w create-file dup . cr throw
^ 3 ERROR_PATH_NOT_FOUND

In Linux it also returns ior from OS as is (without any transforms), but
prints an incorrect error message (due to an incorrect external file
with error messages).

So it behaves similar to iForth in this regard.

I suppose, this behavior is standard compliant too. In this regard the
standard only says:
The values {-4095...-256} shall be used only as assigned by a system.

My conclusion is that it only means that this range shall not be used
for other purposes (i.e. not as assigned by a system).

And it doesn't prohibit a system to use values from the complement
range. Albeit, there is a risk that a program will use a value that the
system uses too.

--
Ruvim

On 7/01/2022 22:52, Anton Ertl wrote:
> ...
> Gforth transforms the OS error numbers (1 and up) into the range of
> Forth system-defined throw codes (-512 and less; Gforth uses
> -511..-256 for signals), and returns it as ior.

That's the arrangement CHForth uses for MS-DOS (OS error codes 1-255)
and which I adopted.

> The user code than
> throws that ior, which is then caught by the system exception handler,
> which transforms the error number back to the OS error number,> and
> uses strerror() to get a string for the error, and prints it.

I don't recall what CHForth does but mine just prints a dumb message
'can't open' etc. to keep the kernel small. For apps where more info
is needed, I have library routines e.g.

: ?OPENERR ( handle ior -- )
dup if
swap cr .fname space $FF and cond
2 of ." file not found" else
3 of ." path not found" else
4 of ." too many open files" else
5 of ." access denied" else
. ." open error"
cont .abort
then 2drop ;

On 8/01/2022 10:52, Ruvim wrote:
>
> I suppose, this behavior is standard compliant too. In this regard the
> standard only says:
> The values {-4095...-256} shall be used only as assigned by a system.
>
> My conclusion is that it only means that this range shall not be used
> for other purposes (i.e. not as assigned by a system).
>
> And it doesn't prohibit a system to use values from the complement
> range. Albeit, there is a risk that a program will use a value that the
> system uses too.

The idea of ANS and systems reserving negative numbers is that programs
could use positive numbers without risk - no?

On 8/01/2022 05:28, minf...@arcor.de wrote:
> Anton Ertl schrieb am Freitag, 7. Januar 2022 um 19:08:54 UTC+1:
>> Krishna Myneni <krishna...@ccreweb.org> writes:
>> >however, it is also useful if the ior(s)
>> >could be made consistent for improved portability of source code.
>> Actually for the way I have used THROW and CATCH, I have not needed to
>> make the iors of OS errors explicit yet; the values come out of the
>> OS/libc are transformed forth and back, and passed back into the libc
>> for conversion into a string.
>>
>> But sure, there can be cases for which it can be useful to check the
>> error code at the Forth level, and for that I would suggest to supply
>> Forth words for (transformed) POSIX errno values. But given the lack
>> of common practice, I don't expect that this would be standardizable
>> soon.
>> >it is
>> >not clear whether or not the intent in Forth-2012 was to standardize the
>> >ior(s) for the file access words.
>> It was certainly not my intent when I agreed with
>> <http://www.forth200x.org/throw-iors.html> to require, e.g.,
>> CREATE-FILE to only ever return 0 or -63. And the standard certainly
>> contains no wording in that direction; I would have voted against such
>> a proposal.
>>
>> Looking at <http://www.forth200x.org/throw-iors.html#comments>:
>>
>> Stephen Pelc points out that the proposal does not say that you must
>> use these throw numbers, it says that if you use these numbers, this
>> is what the standard means by those specific numbers. Consequently
>> gForth will not conflict with the proposal.
>
> When even the oh-so-very-compliant Forths all cook their own dialect,
> things can only get better. ;-)

Careful, you don't want to make yourself an enemy of the state.
They might stop listening to you :)

On 2022-01-08 03:33, dxforth wrote:
> On 8/01/2022 10:52, Ruvim wrote:
>>
>> I suppose, this behavior is standard compliant too. In this regard the
>> standard only says:
>>     The values {-4095...-256} shall be used only as assigned by a system.
>>
>> My conclusion is that it only means that this range shall not be used
>> for other purposes (i.e. not as assigned by a system).
>>
>> And it doesn't prohibit a system to use values from the complement
>> range. Albeit, there is a risk that a program will use a value that the
>> system uses too.
>
> The idea of ANS and systems reserving negative numbers is that programs
> could use positive numbers without risk - no?

Maybe it was intended, but:

1. The corresponding restriction on systems is not declared.
2. This risk is very low (did anybody face its occurrence in practice?).
3. If a program uses libraries, such a risk exists anyway.

Actually, a library is neither a system nor a program. For a system it's
a part of the program, for a program it's a part of the system. A
conception of libraries still waits for its formalization.

As an option to solve the problem of conflicting error codes, a method
to reserve error codes for programs can be developed and standardized.

Probably, since we don't have such a method yet, then the problem is not
so critical in practice too.

--
Ruvim

On 8/01/2022 18:56, Ruvim wrote:
> On 2022-01-08 03:33, dxforth wrote:
>> On 8/01/2022 10:52, Ruvim wrote:
>>>
>>> I suppose, this behavior is standard compliant too. In this regard the
>>> standard only says:
>>>     The values {-4095...-256} shall be used only as assigned by a system.
>>>
>>> My conclusion is that it only means that this range shall not be used
>>> for other purposes (i.e. not as assigned by a system).
>>>
>>> And it doesn't prohibit a system to use values from the complement
>>> range. Albeit, there is a risk that a program will use a value that the
>>> system uses too.
>>
>> The idea of ANS and systems reserving negative numbers is that programs
>> could use positive numbers without risk - no?
>
>
> Maybe it was intended, but:
>
> 1. The corresponding restriction on systems is not declared.
> 2. This risk is very low (did anybody face its occurrence in practice?).
> 3. If a program uses libraries, such a risk exists anyway.
>
> Actually, a library is neither a system nor a program. For a system it's
> a part of the program, for a program it's a part of the system. A
> conception of libraries still waits for its formalization.
>
>
> As an option to solve the problem of conflicting error codes, a method
> to reserve error codes for programs can be developed and standardized.
>
> Probably, since we don't have such a method yet, then the problem is not
> so critical in practice too.

"Programs shall not define values for use with THROW in the range {-4095...-1}."

I was mistaken about positive values - any code outside -4095...-1 may be used.
The corollary is that systems are restricted to that range. A library that
extends the system is no different from the system; one that extends the program
is no different from the program.

On 2022-01-08 11:42, dxforth wrote:
> On 8/01/2022 18:56, Ruvim wrote:
>> On 2022-01-08 03:33, dxforth wrote:
>>> On 8/01/2022 10:52, Ruvim wrote:
>>>>
>>>> I suppose, this behavior is standard compliant too. In this regard the
>>>> standard only says:
>>>>     The values {-4095...-256} shall be used only as assigned by a
>>>> system.
>>>>
>>>> My conclusion is that it only means that this range shall not be used
>>>> for other purposes (i.e. not as assigned by a system).
>>>>
>>>> And it doesn't prohibit a system to use values from the complement
>>>> range. Albeit, there is a risk that a program will use a value that the
>>>> system uses too.
>>>
>>> The idea of ANS and systems reserving negative numbers is that programs
>>> could use positive numbers without risk - no?
>>
>>
>> Maybe it was intended, but:
>>
>> 1. The corresponding restriction on systems is not declared.
>> 2. This risk is very low (did anybody face its occurrence in practice?).
>> 3. If a program uses libraries, such a risk exists anyway.
>>
>> Actually, a library is neither a system nor a program. For a system it's
>> a part of the program, for a program it's a part of the system. A
>> conception of libraries still waits for its formalization.
>>
>>
>> As an option to solve the problem of conflicting error codes, a method
>> to reserve error codes for programs can be developed and standardized.
>>
>> Probably, since we don't have such a method yet, then the problem is not
>> so critical in practice too.
>
> "Programs shall not define values for use with THROW in the range
> {-4095...-1}."
>
> I was mistaken about positive values - any code outside -4095...-1 may
> be used.
> The corollary is that systems are restricted to that range.

This corollary is based on an assumption that is not declared in the
normative part. So it's a formal fallacy.

> A library that extends the system is no different from the system;
> one that extends the program is no different from the program.

What is a criterion to determine whether a library extends the system or
not?

Is it possible that a library in one case extends a system, in another
case it extends a program?

--
Ruvim

dxforth <dxforth@gmail.com> writes:
>The idea of ANS and systems reserving negative numbers is that programs
>could use positive numbers without risk - no?

My impression is that the idea was that the standard would define
throw codes -255..-1 (and of course that 0 does not throw), systems
would define throw codes -4095..-256, and all other throw codes would
be left to the applications.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-01-08 03:33, dxforth wrote:
>> The idea of ANS and systems reserving negative numbers is that programs
>> could use positive numbers without risk - no?
>
>
>Maybe it was intended, but:
>
>1. The corresponding restriction on systems is not declared.

What would be the corresponding restriction on systems, and how would
it be specified?

Maybe:

1) Unless asked for by the program with THROW, a systems throws only in
the range -4095..-1.

1a) System-internal THROWs in the range -255..-1 are caused by
events that correspond to the escription in table 9-1 (there is
still lots of wiggle room there, and it's sometimes necessary; e.g.,
if the OS is not as capable as one might like, or if you PICK deep
enough, you get an "invalid memory" exception instead of a "stack
underflow" in Gforth).

2) Error codes (iors) returned by standard words are in the range
-4095..0.

>2. This risk is very low (did anybody face its occurrence in practice?).

I tend to avoid defining new throw codes, partly because standard
Forth does not have a good way to do it. I Gforth I have such a way,
but I have also defined few new throw codes in Gforth-specific programs. Maybe we don't need that that often

>3. If a program uses libraries, such a risk exists anyway.
....
>As an option to solve the problem of conflicting error codes, a method
>to reserve error codes for programs can be developed and standardized.

Many years ago (in 1999 or earlier) I have proposed

http://www.forth200x.org/exception.html

This is a pre-Forth-200x proposal that I never bothered to propose for
Forth200x.

>Probably, since we don't have such a method yet, then the problem is not
>so critical in practice too.

Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
picked up EXCEPTION. This is probably because need for defining throw
codes in libraries is rare, and I guess the low importance of
libraries in Forth also plays a role. Anyway, if you want to write a
library for Gforth, Gforth has had EXCEPTION since at least 1998.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Ruvim <ruvim.pinka@gmail.com> writes:
>On 2022-01-08 11:42, dxforth wrote:
>> I was mistaken about positive values - any code outside -4095...-1 may
>> be used.
>> The corollary is that systems are restricted to that range.
>
>This corollary is based on an assumption that is not declared in the
>normative part. So it's a formal fallacy.

Sure, if you want to language-lawyer a broken implementation into
standards-conformance (say, like what I read about the VMS and
MicroSoft POSIX implementations). If OTOH you want to provide a
high-quality implementation, your system will not throw values outside
-4095..-1 unless the program asks for that through THROW. And it will
not return iors outside that range.

>> A library that extends the system is no different from the system;
>> one that extends the program is no different from the program.
>
>What is a criterion to determine whether a library extends the system or
>not?
>
>Is it possible that a library in one case extends a system, in another
>case it extends a program?

I don't know what dxforth means, but there is such a difference: A
library that is provided independent of systems cannot know what throw
codes are used by the system, and so has to define throw codes outside
the -4095..0 range. OTOH, a library that is provided by the system
implementor for a specific system can know which throw codes the
system uses and in that case the lowest collision risk is if the
library uses throw codes in the -4095..-1 range that are not used by
anything else in the system (nor any other system library).

As an example, the version of EXCEPTION in the compat library uses
numbers outside the -4095..-1 range, while the version of EXCEPTION
built into Gforth uses numbers inside that range.

- 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: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 2022-01-08 13:21, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 03:33, dxforth wrote:
>>> The idea of ANS and systems reserving negative numbers is that programs
>>> could use positive numbers without risk - no?
>>
>>
>> Maybe it was intended, but:
>>
>> 1. The corresponding restriction on systems is not declared.
>
> What would be the corresponding restriction on systems, and how would
> it be specified?
>
> Maybe:
>
> 1) Unless asked for by the program with THROW, a systems throws only in
> the range -4095..-1.
>
> 1a) System-internal THROWs in the range -255..-1 are caused by
> events that correspond to the escription in table 9-1 (there is
> still lots of wiggle room there, and it's sometimes necessary; e.g.,
> if the OS is not as capable as one might like, or if you PICK deep
> enough, you get an "invalid memory" exception instead of a "stack
> underflow" in Gforth).
>
> 2) Error codes (iors) returned by standard words are in the range
> -4095..0.

For all standard words that return unspecified ior, the standard says:
"ior is the implementation-defined I/O result code".

So, a restriction on systems can be specified as follows:

Any implementation-defined I/O result code
_shall_ be in the range -4095..0

A system choosing to execute THROW when detecting one
of the ambiguous conditions listed in table 9.1
_should_ use the throw code listed there. Otherwise
a throw code _shall_ be in the range -4095..-256.

But at the moment I would be against such a restriction on systems. It
seems to me, it doesn't solve any actual problem. But it creates a new
problem.

For example, take a look at the Windows error codes:
https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes

They are in the range 0..15999.

How do you suggest to map them into the range -4095..-256 ?

It's possible, with some limitations, but it's not easy.

>> 2. This risk is very low (did anybody face its occurrence in practice?).

I never faced a materialization of this risk. Did you?

> I tend to avoid defining new throw codes, partly because standard
> Forth does not have a good way to do it. I Gforth I have such a way,
> but I have also defined few new throw codes in Gforth-specific programs.
> Maybe we don't need that that often
>
>> 3. If a program uses libraries, such a risk exists anyway.
> ...
>> As an option to solve the problem of conflicting error codes, a method
>> to reserve error codes for programs can be developed and standardized.
>
> Many years ago (in 1999 or earlier) I have proposed
>
> http://www.forth200x.org/exception.html
>
> This is a pre-Forth-200x proposal that I never bothered to propose for
> Forth200x.
>
>> Probably, since we don't have such a method yet, then the problem is not
>> so critical in practice too.
>
> Yes: Checking iForth, lxf, SwiftForth, and VFX, none of them has
> picked up EXCEPTION. This is probably because need for defining throw
> codes in libraries is rare, and I guess the low importance of
> libraries in Forth also plays a role. Anyway, if you want to write a
> library for Gforth, Gforth has had EXCEPTION since at least 1998.

I use another approach. I use textual identifies for errors. For that I
use a system-dependent word STHROW

STHROW ( c-addr u -- )
Set the string (c-addr u) as an error message and perform
the function of -2 THROW

The implementation: https://git.io/J9sK1

I use it a lot, see: https://github.com/rufig/spf4-utf8/search?q=STHROW

--
Ruvim

On 2022-01-08 13:55, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 11:42, dxforth wrote:
>>> I was mistaken about positive values - any code outside -4095...-1 may
>>> be used.
>>> The corollary is that systems are restricted to that range.
>>
>> This corollary is based on an assumption that is not declared in the
>> normative part. So it's a formal fallacy.
>
> Sure, if you want to language-lawyer a broken implementation into
> standards-conformance (say, like what I read about the VMS and
> MicroSoft POSIX implementations).

If a Forth system implementation uses ior codes outside of the range
-4095..0, it doesn't make it broken.

And Forth-94 explicitly only _recommends_ to use nonzero iors from the
range -4095...-256

| 9.3.1 THROW values
| | The THROW values {-255...-1} shall be used only as
| assigned by this Standard. The values {-4095...-256}
| shall be used only as assigned by a system.

| If the File-Access or Memory-Allocation word sets are
| implemented, it is recommended that the non-zero values
| of ior lie within the range of system THROW values, as
| defined above.

If a Forth system can't provide error messages for error codes from the
OS, then using the error codes from the OS (when it's outside of
{-255...0}) as an ior makes life simpler for users since it allows to
recover an initial error meaning more easily.

> If OTOH you want to provide a
> high-quality implementation, your system will not throw values outside
> -4095..-1 unless the program asks for that through THROW. And it will
> not return iors outside that range.

Probably, a more high-quality approach would be something like exception
objects that can contain additional information and can be nested.

After all, a less quality system doesn't mean that it's a broken system.

--
Ruvim

On 2022-01-08 13:55, Anton Ertl wrote:
> Ruvim <ruvim.pinka@gmail.com> writes:
>> On 2022-01-08 11:42, dxforth wrote:

>>> A library that extends the system is no different from the system;
>>> one that extends the program is no different from the program.
>>
>> What is a criterion to determine whether a library extends the system or
>> not?
>>
>> Is it possible that a library in one case extends a system, in another
>> case it extends a program?
>
> I don't know what dxforth means, but there is such a difference: A
> library that is provided independent of systems cannot know what throw
> codes are used by the system, and so has to define throw codes outside
> the -4095..0 range. OTOH, a library that is provided by the system
> implementor for a specific system can know which throw codes the
> system uses and in that case the lowest collision risk is if the
> library uses throw codes in the -4095..-1 range that are not used by
> anything else in the system (nor any other system library).

Does it mean that if some vendor includes some portable library into its
system, it should also change the throw codes in this library to the
-4095..-256 range?

> As an example, the version of EXCEPTION in the compat library uses
> numbers outside the -4095..-1 range, while the version of EXCEPTION
> built into Gforth uses numbers inside that range.

So a third-party library should not use the built-in EXCEPTION word when
it runs in Gforth to avoid -4095..-1 range, should it?

--
Ruvim

On 9/01/2022 02:27, Ruvim wrote:
>
> So, a restriction on systems can be specified as follows:
>
> Any implementation-defined I/O result code
> _shall_ be in the range -4095..0
>
> ...
>
> But at the moment I would be against such a restriction on systems. It
> seems to me, it doesn't solve any actual problem

Other than stupidity:

"St. Peter, there was no sign saying 'Beware of the Pit' so I exercised
my right and jumped in."

> But it creates a new
> problem.
>
> For example, take a look at the Windows error codes:
> https://docs.microsoft.com/en-us/windows/win32/debug/system-error-codes
>
> They are in the range 0..15999.
>
> How do you suggest to map them into the range -4095..-256 ?
>
> It's possible, with some limitations, but it's not easy.

The world is full of causes that clamour for attention. Do you support
them all - or just those you consider deserving?