From: user5857@newsgrouper.org.invalid
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.
> Niklas
>
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
