From: cross@spitfire.i.gajendra.net   
      
   In article ,   
   Scott Lurndal  wrote:   
   >cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>In article <2025Aug13.232334@mips.complang.tuwien.ac.at>,   
   >>Anton Ertl  wrote:   
   >>>cross@spitfire.i.gajendra.net (Dan Cross) writes:   
   >>>>In article <2025Aug13.181010@mips.complang.tuwien.ac.at>,   
   >>>>Anton Ertl  wrote:   
   >>>>>For lseek(2):   
   >>>>>   
   >>>>>| Upon successful completion, lseek() returns the resulting offset   
   >>>>>| location as measured in bytes from the beginning of the file.   
   >>>>>   
   >>>>>Given that off_t is signed, lseek(2) can only return positive values.   
   >>>>   
   >>>>This is incorrect; or rather, it's accidentally correct now, but   
   >>>>was not previously.  The 1990 POSIX standard did not explicitly   
   >>>>forbid a file that was so large that the offset couldn't   
   >>>>overflow, hence why in 1990 POSIX you have to be careful about   
   >>>>error handling when using `lseek`.   
   >>>>   
   >>>>It is true that POSIX 2024 _does_ prohibit seeking so far that   
   >>>>the offset would become negative, however.   
   >>>   
   >>>I don't think that this is accidental.  In 1990 signed overlow had   
   >>>reliable behaviour on common 2s-complement hardware with the C   
   >>>compilers of the day.   
   >>   
   >>This is simply not true.  If anything, there was more variety of   
   >>hardware supported by C90, and some of those systems were 1's   
   >>complement or sign/mag, not 2's complement.  Consequently,   
   >>signed integer overflow has _always_ had undefined behavior in   
   >>ANSI/ISO C.   
   >   
   >Both Burroughs Large Systems (48-bit stack machine) and the   
   >Sperry 1100/2200 (36-bit) systems had (have, in emulation today)   
   >C compilers.   
      
   Yup.  The 1100-series machines were (are) 1's complement.  Those   
   are the ones I usually think of when cursing that signed integer   
   overflow is UB in C.   
      
   I don't think anyone is compiling C23 code for those machines,   
   but back in the late 1980s, they were still enough of a going   
   concern that they could influence the emerginc C standard.  Not   
   so much anymore.   
      
   Regardless, signed integer overflow remains UB in the current C   
   standard, nevermind definitionally following 2s complement   
   semantics.  Usually this is done on the basis of performance   
   arguments: some seemingly-important loop optimizations can be   
   made if the compiler can assert that overflow Cannot Happen.   
      
   And of course, even today, C still targets oddball platforms   
   like DSPs and custom chips, where assumptions about the ubiquity   
   of 2's comp may not hold.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)