Re: THROW codes and ambiguous conditions

Liste des GroupesRevenir à cl forth 
Sujet : Re: THROW codes and ambiguous conditions
De : albert (at) *nospam* spenarnc.xs4all.nl
Groupes : comp.lang.forth
Date : 01. Jun 2025, 18:35:37
Autres entêtes
Organisation : KPN B.V.
Message-ID : <nnd$5c501e87$383f11cb@111e56d389a8750e>
References : 1 2 3 4
User-Agent : trn 4.0-test77 (Sep 1, 2010)
In article <2025Jun1.171542@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
albert@spenarnc.xs4all.nl writes:
Actually, the error returns from system calls are negative
numbers. So I do approximately:
   ( open file )  DUP 0 MIN THROW \ Now the result is a file channel id.
So I was puzzled at the term remapping. Indeed the man 3 errno
reveals that positive numbers are intended.
>
It depends on the architecture how an error from a system call is
indicated; on some architectures the result is only returned in one
register, on some it's a register and a flag (IIRC the carry flag).

I have experience in Intel. (ciforth=common intel Forth).
In a surprising large number of Intel : 32/64 MS linux openbsd intel-osx
the result is returned in AX.
On ARM linux R0 is used.
On riscv linux a0 is used.
The unix like community is consistent in this.
Unfortunately Microsoft tells to find the meaning in the hard to find
documentation, so it is call dependant. But for a large class of ddl
calls this convention is upheld, at least for the SYSTEM32.SYS stuff.
"DUP 0 MIN" often finds an error code, but I must combine it with the
result of GetLastError@0 sometimes.
Note that dll's are not only "system calls", Anybody can write a dll
library and make a dogs dinner out of it and forget to document.
In this respect dll's are more like .so files.

>
In the latter case a set flag indicates that the register contains an
error code, while a clear flag indicates that there was no error and
the register contains the result.
>
If there is only one register, you have to find out it the result is a
success or an error.  Many system calls are designed to produce a
positive result (e.g., write() or read()), and using the negative
number range for error results is the solution for that; that's why
you are seeing the negated errno.
>
It becomes tricky to do system calls like sbrk() and mmap() that
return addresses, because in principle any bit pattern can be an
address.  But originally Unix and Linux reserved the high half of
address space for the system, so these system calls, which return
user-level addresses, could only return addresses where the MSB is
clear.  Towards the end of the 32-bit era, user space could reach up
to 3GB, so just checking the sign was not enough, but there was still
1G of numbers that could be used as error returns.

So far so good. This system holds surprisingly well.

>
This discussion proves that adhering to
the exact throw cause is of dubious value.
>
There is apparently little usage of catching specific throw codes.
E.g., I have never done that.
>
However, throwing specific codes is a different issue.  I have done
so, and I have discussed with other people which existing throw codes
are appropriate for which error.  An example is shown in
<2024Apr1.115659@mips.complang.tuwien.ac.at>:
>
: gen-mask3 ( n -- x )
 \ throw if <n>=0
 64 swap - dup 64 u< 0= -24 and throw -1 swap lshift ;
>
Will 0 GEN-MASK3 give the error message "Too many open files" or
"Invalid numeric argument" on ciforth?

0 gen-mask3 ? ciforth ERROR # -24 : Too many open files

(Not OK).

>
- anton
--
Temu exploits Christians: (Disclaimer, only 10 apostles)
Last Supper Acrylic Suncatcher - 15Cm Round Stained Glass- Style Wall
Art For Home, Office And Garden Decor - Perfect For Windows, Bars,
And Gifts For Friends Family And Colleagues.

Date Sujet#  Auteur
31 May 25 * THROW codes and ambiguous conditions37dxf
31 May 25 +* Re: THROW codes and ambiguous conditions7Anton Ertl
31 May 25 i+* Re: THROW codes and ambiguous conditions2dxf
3 Jun21:48 ii`- Re: THROW codes and ambiguous conditions1sjack
31 May 25 i`* Re: THROW codes and ambiguous conditions4Anton Ertl
1 Jun 25 i `* Re: THROW codes and ambiguous conditions3albert
1 Jun 25 i  `* Re: THROW codes and ambiguous conditions2Anton Ertl
1 Jun 25 i   `- Re: THROW codes and ambiguous conditions1albert
1 Jun 25 `* Re: THROW codes and ambiguous conditions29Hans Bezemer
2 Jun05:58  +- Re: THROW codes and ambiguous conditions1dxf
2 Jun11:44  `* Re: THROW codes and ambiguous conditions27albert
3 Jun04:23   `* Re: THROW codes and ambiguous conditions26dxf
3 Jun07:10    +* Re: THROW codes and ambiguous conditions22Anton Ertl
4 Jun15:44    i`* Re: THROW codes and ambiguous conditions21dxf
4 Jun20:25    i `* Re: THROW codes and ambiguous conditions20sean
5 Jun07:09    i  +- Re: THROW codes and ambiguous conditions1dxf
5 Jun11:17    i  `* Re: THROW codes and ambiguous conditions18albert
6 Jun01:47    i   +- Re: THROW codes and ambiguous conditions1dxf
6 Jun07:15    i   `* Re: THROW codes and ambiguous conditions16sean
6 Jun12:00    i    `* Re: THROW codes and ambiguous conditions15albert
6 Jun22:06    i     `* Re: THROW codes and ambiguous conditions14sean
7 Jun04:10    i      `* Re: THROW codes and ambiguous conditions13dxf
7 Jun05:26    i       `* Re: THROW codes and ambiguous conditions12sean
7 Jun05:42    i        +- Re: THROW codes and ambiguous conditions1dxf
7 Jun10:43    i        +* Re: THROW codes and ambiguous conditions9Anton Ertl
7 Jun15:06    i        i`* Re: THROW codes and ambiguous conditions8dxf
7 Jun20:58    i        i `* Re: THROW codes and ambiguous conditions7Paul Rubin
8 Jun02:49    i        i  +* Re: THROW codes and ambiguous conditions3Paul Rubin
8 Jun04:36    i        i  i+- Re: THROW codes and ambiguous conditions1dxf
8 Jun09:07    i        i  i`- Re: THROW codes and ambiguous conditions1Anton Ertl
8 Jun03:16    i        i  +- Re: THROW codes and ambiguous conditions1dxf
8 Jun08:56    i        i  `* Re: THROW codes and ambiguous conditions2Anton Ertl
8 Jun15:45    i        i   `- Re: THROW codes and ambiguous conditions1dxf
7 Jun15:41    i        `- Re: THROW codes and ambiguous conditions1LIT
3 Jun09:43    +- Re: THROW codes and ambiguous conditions1John
4 Jun03:03    `* Re: THROW codes and ambiguous conditions2dxf
6 Jun11:47     `- Re: THROW codes and ambiguous conditions1Hans Bezemer

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal