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: Sat, 14 Dec 2024 14:22:03 -0800
Organization: None to speak of
Lines: 89
Message-ID: <877c81vras.fsf@nosuchdomain.example.com>
References: <vi54e9$3ie0o$1@dont-email.me> <20241129142810.00007920@yahoo.com>
	<vicfra$13nl4$1@dont-email.me> <20241129161517.000010b8@yahoo.com>
	<vicque$15ium$2@dont-email.me> <vid110$16hte$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>
	<vin7r2$49d1$2@dont-email.me> <vinalt$5qoh$1@dont-email.me>
	<vipgns$rjqn$1@dont-email.me> <viqbl8$12mum$1@dont-email.me>
	<viqfuh$131h8$2@dont-email.me> <vjkp5b$27hva$1@paganini.bofh.team>
	<vjktle$5sfr$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 14 Dec 2024 23:22:07 +0100 (CET)
Injection-Info: dont-email.me; posting-host="f020b395aa19c836e8bce37085be125e";
	logging-data="208467"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/RKCx/+2SaR5aw1AE+kWuf"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:ohpNl2FETZDWHg2xdjp4k+pN/cc=
	sha1:By1TpIqsPqcyN0ekwXHnBL4UIGo=
Bytes: 3982

bart <bc@freeuk.com> writes:
> On 14/12/2024 20:17, Waldek Hebisch wrote:
>> Bart <bc@freeuk.com> wrote:
[...]
> For the same reason that f(1 2 3) might be unambiguous, as usually
> it's written f(1, 2, 3).
>
> Actually, since C likes to declare/define lists of things where other
> languages don't allow them, such as:
>
>  typedef int T, U, *V;
>
>  struct tag {int x;} a, b, c;
>
>  enum {red, green} blue, yellow;
>
> I couldn't quite see why you can't do the same with functions:
>
>  int F(void){return 1;}, G(void){return 2;}

Those are function *definitions*.  Declarations, including function
declarations, can be bundled :

    int F(void), G(void); // not suggesting this is good style

Definitions that are not declarations, such as function definitions,
cannot.

I thought you liked consistency.

If the language allowed function definitions to be bundled, you could
write something like :

    int F(void) {
        // 30 lines of code
    }, G(void) {
        // 50 lines of code
    }

Is that what you want?

[...]

> Now that you mention it, why not? In:
>
>   if (c) s1; else s2;
>
> s1 and s2 are statements, but so is the whole if-else construct; why
> doesn't that need its own terminator?

Because if it did, you'd need multiple semicolons at the end of nested
statements.  Is that what you want?

You seem to be pretending that there's some principle that all
statements should be terminated by semicolons.  There is no such
principle, and there are multiple kinds of statements that don't
require a trailing semicolon.

> This is legal in C: {}{}{}{}.
>
> As I said, I wouldn't be able to explain it.

I could explain it to you, but I can't understand it for you.

[...]

> Identifying the end of /some/ statements shouldn't mean not needing
> terminators in those cases. It needs to be a consistent rule.

Why?  C's grammar is unambiguous.  Given reasonable code layout, most C
programmers don't have any problems determining where statements end.
With your "consistent rule", if you had 5 nested statements (if, for,
while, etc.), you'd have to terminate the entire construct at least 5
semicolons.

Is that really what you want?

[...]

> But the exact rules remain fuzzy.

The exact rules are not fuzzy.  They're unambiguous, and they work much
better than you're willing to acknowledge.

[discussion of your personal language snipped]

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