Re: THROW codes and ambiguous conditions

Liste des GroupesRevenir à cl forth 
Sujet : Re: THROW codes and ambiguous conditions
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.lang.forth
Date : 01. Jun 2025, 16:15:42
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2025Jun1.171542@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5
User-Agent : xrn 10.11
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).

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.

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?

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

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