Re: question about linker

On 12/12/2024 01:27, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

My experience of multi-level break is that there are two main use-cases:
>
  * Used in the current loop only (not necessarily the innermost to an
    observer). This is the most common
>
  * Used to exit the outermost loop
>
So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)

 I would oppose a change to C that only applied to innermost and
outermost loops.  For one thing, I'm not aware of any other language
that does this (except perhaps your unnamed one).  For another,
it's easy enough to define a feature that handles any arbitrary
nesting levels, by applying names (labels) to loops.
 

Having named labels do have some advantages, such as being absolute
while indices are relative. But sometimes you need an absolute
reference when refactoring and sometimes you want it relative.

 I'm not sure what you mean by "relative".  Do you have an example?
 If, say, I have a "break 2" statement (the Bourne shell uses that
syntax), and I wanted to refactor the code, I'll at least have
to pay very close attention to the number, and likely change it.
Is that what you mean by "relative"?  If I have "break NAME", it's
more likely that I won't have to change it.  (Disclaimer: I don't
think I've ever used the "break N" feature of the Bourne shell.)

Take these two loops:
    loop A: {
        loop B: {
            break A            // absolute
            break +1;          // relative
        }
    }
The two breaks in the inner one both break out of the outer loop. The relative one uses an index counting outwards.
Now suppose you add a third loop C in between A and B. Those two breaks now do different things: 'break A' is still the outermost, but 'break +1' now exist from loop C.
Sometimes you will want one behaviour and sometimes the other. So you can't say one is better. I don't have enough experience of them to say (my 'exit' and 'exit all' are effectively both absolute).
Another issue is when you move or copy a block of code (say those two breaks) into another loop. That 'break +1' might be OK, but probably not 'break A'. (You don't want to break out of an unrelated loop in a different part of the function; using 'goto' would allow that.)

If duplicating within the same function, then you also need to think
about scope rules for those named labels.

 That's hardly the only case where duplicating code within a function
can cause conflicts.
 A common proposal is to use existing labels, whose scope is already
well defined.  Labels have *function scope*.  You just have to make
sure that all labels within a function are unique.

If function-wide label scope is used, then my A and B labels need to be unique, so copying code around is harder. If loop scopes are private, then you can do this:
    loop A: {
        loop A: {
which doesn't look useful. It's all a fiddly bit of language design, which is why I kept it simple.