Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Wed, 11 Dec 2024 17:27:53 -0800
Organization: None to speak of
Lines: 44
Message-ID: <87frmtwuzq.fsf@nosuchdomain.example.com>
References: <vi54e9$3ie0o$1@dont-email.me> <vifcll$1q9rj$1@dont-email.me>
	<vifiib$1s07p$1@dont-email.me> <87ldwx10gv.fsf@bsb.me.uk>
	<vimtt4$27vv$1@dont-email.me> <86ser1kgp5.fsf@linuxsc.com>
	<vit69t$1qfgg$1@dont-email.me>
	<87ldwtzlc0.fsf@nosuchdomain.example.com>
	<vitjgg$1tukq$2@dont-email.me> <vj1bss$325uo$1@dont-email.me>
	<vj1h4i$335q1$2@dont-email.me> <vj1mhi$34p7h$1@dont-email.me>
	<vj1prj$35je4$1@dont-email.me> <vj7dup$he7i$1@dont-email.me>
	<vjasuj$17uod$1@dont-email.me> <vjc87h$1apid$1@paganini.bofh.team>
	<vjcbe1$1jns0$1@dont-email.me>
	<87wmg5x4b1.fsf@nosuchdomain.example.com>
	<vjd96b$1pbed$1@dont-email.me>
	<87jzc5wx3s.fsf@nosuchdomain.example.com>
	<vjdde8$1q2to$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 12 Dec 2024 02:27:54 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fce124256618fa8243377af1ae3d31f3";
	logging-data="1900317"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+jyCwxPUmdH5Jo7UnjNqI2"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:Tpy7JqYBj95V/XmIkb2iKPZYEPo=
	sha1:i7xgbkWHYjH6DuxrXAacsOKdNsQ=
Bytes: 3475

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.)

> 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.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */