From: niklas.holsti@tidorum.invalid   
      
   On 2025-11-05 18:23, BGB wrote:   
   > On 11/5/2025 9:26 AM, Niklas Holsti wrote:   
   >> On 2025-11-05 7:17, Anton Ertl wrote:   
   >>   
   >>     [ snip ]   
   >>   
   >>> Yes, assigned goto and labels-as-values (and probably the Cobol   
   >>> alter/goto and PL/1 label variables) are there because computer   
   >>> architectures have indirect branches and the programming language   
   >>> designer wanted to give the programmers a way to express what they   
   >>> would otherwise have to express in assembly language.   
   >>>   
   >>> Why does standard C not have it?  C had it up to and including the 6th   
   >>> edition Unix <3714DA77.6150C99A@bell-labs.com>, but it went away   
   >>> between 6th and 7th edition.  Ritchie wrote   
   >>> <37178013.A1EE3D4F@bell-labs.com>:   
   >>>   
   >>> | I eliminated them because I didn't know what to say about their   
   >>> | semantics.   
   >>>   
   >>> Stallman obviously knew what to say about their semantics when he   
   >>> added labels-as-values to GNU C with gcc 2.0.   
   >>   
   >>   
   >> I don't know what Stallman said, or would have said if asked, but I   
   >> guess something like "the semantics is a jump to the (address of the)   
   >> label to which the value refers", which is machine-level semantics and   
   >> not semantics in the abstract C machine.   
   >>   
   >> The problem in the abstract C machine is a "goto label-value"   
   >> statement where the label-value refers to a label in a different   
   >> function. Does gcc prevent that at compile time? If not, I would   
   >> expect the semantics to be Undefined Behavior, the usual cop-out when   
   >> nothing useful can be said.   
   >>   
   >> (In an earlier discussion on this group, some years ago, I explained   
   >> how labels-as-values could be added to Ada, using the type system to   
   >> ensure safe and defined semantics. But I don't think such an extension   
   >> would be accepted for the Ada standard.)   
   >>   
   >   
   > My guess here:   
   > It is an "oh crap" situation and program either immediately or (maybe   
   > not as immediately) explodes...   
      
   Or silently produces wrong results.   
      
   > Otherwise, it would need to function more like a longjmp, which would   
   > mean that it would likely be painfully slow.   
      
   But then you could get the problem of a longjmp to a setjmp value that   
   is stale because the targeted function invocation (stack frame) is no   
   longer there.   
      
   Niklas   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)