From: cross@spitfire.i.gajendra.net   
      
   In article , Scott Lurndal  wrote:   
   >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:   
   >>scott@slp53.sl.home (Scott Lurndal) writes:   
   >>[snip]   
   >>errno, but at the actual system call level, the error is indicated in   
   >>an architecture-specific way, and the ones I have looked at before   
   >>today use the sign of the result register or the carry flag.  On those   
   >>architectures, where the sign is used, mmap(2) cannot return negative   
   >>addresses, or must have a special wrapper.   
   >   
   >Why would the wrapper care if the system call failed?  The   
   >return value from the kernel should be passed through to   
   >the application as per the POSIX language binding requirements.   
      
   For the branch to `cerror`.  That is, the usual reason is (was?)   
   to convert from the system call interface to the C ABI,   
   specifically, to populate the (userspace, now thread-local)   
   `errno` variable if there was an error.  (I know you know this,   
   Scott, but others reading the discussion may not.)   
      
   Looking at the 32v code for VAX and 7th Edition on the PDP-11,   
   on error the kernel returns a non-zero value and sets the carry   
   bit in the PSW.  The stub checks whether the C bit is set, and   
   if so, copies R0 to `errno` and then sets R0 to -1.  On the   
   PDP-11, `as` supports the non-standard "bec" mnemonic as an   
   alias for "bcc" and the stub is actually something like:   
      
       / Do sys call....land in the kernel `trap` in m40.s   
       bec 1f   
       jmp cerror   
   1f:   
       rts pc   
      
   cerror:   
       mov r0, _errno   
       mov $-1, r0   
       rts pc   
      
   In other words, if the carry bit is not set, there system call   
   was successful, so just return whatever it returned.  Otherwise,   
   the kernel is returning an error to the user, so do the dance of   
   setting up `errno` and returning -1.   
      
   (There's some fiddly bits with popping R5, which Unix used as   
   the frame pointer, but I omitted those for brevity).   
      
   >lseek(2) and mmap(2) both require the return of arbitrary 32-bit   
   >or 64-bit values, including those which when interpreted as signed   
   >values are negative.   
      
   At last for lseek, that was true in the 1990 POSIX standard,   
   where the programmer was expected to (maybe save and then) clear   
   `errno`, invoke `lseek`, and then check the value of `errno`   
   after return to see if there was an error, but has been relaxed   
   in subsequent editions (include POSIX 2024) where `lseek` now   
   must return `EINVAL` if the offset is negative for a regular   
   file, directory, or block-special file.   
   (https://pubs.opengroup.org/onlinepubs/9799919799/functions/lseek.html;   
   see "ERRORS")   
      
   For mmap, at least the only documented error return value is   
   `MAP_FAILED`, and programmers must check for that explicitly.   
      
   It strikes me that this implies that the _value_ of `MAP_FAILED`   
   need not be -1; on x86_64, for instance, it _could_ be any   
   non-canonical address.   
      
   >Clearly POSIX defines the interfaces and the underlying OS and/or   
   >library functions implement the interfaces.   The kernel interface   
   >to the language library (e.g. libc) is irrelevent to typical programmers,   
   >except in the case where it doesn't provide the correct semantics.   
      
   Certainly, these are hidden by the system call stubs in the   
   libraries for language-specific bindings, and workaday   
   programmers should not be trying to side-step those!   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)