From: niklas.holsti@tidorum.invalid   
      
   On 2025-11-05 23:28, MitchAlsup wrote:   
   >   
   > Niklas Holsti  posted:   
   >   
   >> 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.   
   >   
   > But YOU had to pass the jumpbuf out of the setjump() scope.   
   >   
   > Now, YOU complain there is a hole in your own foot with a smoking gun   
   > in your own hand.   
      
   That is not the issue. The question is if the semantics of "goto   
   label-valued-variable" are hard to define, as Ritchie said, or not, as   
   Anton thinks Stallman said or would have said.   
      
   The discussion above shows that whether a label value is implemented as   
   a bare code address, or as a jumpbuf, some cases will have Undefined   
   Behavior semantics. So I think Ritchie was right, unless the undefined   
   cases can be excluded at compile time.   
      
   The undefined cases could be excluded at compile-time, even in C, by   
   requiring all label-valued variables to be local to some function and   
   forbidding passing such values as parameters or function results. In   
   addition, the use of an uninitialized label-valued variable should be   
   prevented or detected. Perhaps Anton could accept such restrictions.   
      
   Niklas   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)