Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: question about linker Date: Sat, 14 Dec 2024 14:54:06 -0800 Organization: None to speak of Lines: 116 Message-ID: <8734ipvptd.fsf@nosuchdomain.example.com> References: <20241129142810.00007920@yahoo.com> <20241129161517.000010b8@yahoo.com> <87ldwx10gv.fsf@bsb.me.uk> <877c81vras.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 14 Dec 2024 23:54:07 +0100 (CET) Injection-Info: dont-email.me; posting-host="f020b395aa19c836e8bce37085be125e"; logging-data="208467"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19KJivHiaYhPRvYrl3Atu33" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:2OPXdYh8Td0UBskZ9WpzrutK9EY= sha1:M6mGgq8rJsGh7vHEUSif60gnjJo= Xref: csiph.com comp.lang.c:389663 bart writes: > On 14/12/2024 22:22, Keith Thompson wrote: >> bart writes: >>> On 14/12/2024 20:17, Waldek Hebisch wrote: >>>> Bart 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. > > Consistency would mean function definitions could be 'bundled' too. Declarations can be bundled. Function definitions cannot. More generally, some things can be bundled, and other things cannot. The existing rules are consistent. What else do you think should be able to be bundled? Macro definitions? Include directives? #include , ; // ??? C is not 100% consistent and orthogonal. It was never intended to be. Every here knows that it isn't. If you want Lisp, whose syntax rules are simpler than C's, you know where to find it. Google "foolish consistency". >> If the language allowed function definitions to be bundled [...] > I don't care about it. Excellent. Then let's drop it. > I just wondered why not since such lists are > allowed elsewhere. I've explained that. >> [...] >> >>> 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? > > No of course not. But I'm trying to shed light on the odd rules in > language; Yes, C has some odd rules. Why must you keep telling us something we already know? > S1; S2; S3; > > where: > > #define S1 if (c) a; > #define S2 if (c) {a;} > #define S3 if (c) a > > The end result is: > > if (c) a;; if (c) {a;}; if (c) a; > > It's messy. Also, is the semicolon considered part of the statement, > or is it administered by whoever is assembling the statements within > the bigger picture? Yes, ugly code is ugly. If I see ugly code, blame the author of the code, not the author of the language that made it possible. [...] > As I said, the whole thing is starting to look like a hack just so you > /don't/ end up with sequences of semicolons. I doubt that the issue of sequences of semicolons even occurred to Thompson and Ritchie. They just designed a consistent syntax -- perhaps not the best possible, but one that works. I speculate that they didn't think about sequences of semicolons because, unlike you, it never occurred to them that there is or should be a rule that all statements are terminated by semicolons. You're very good at inventing problems. You're less good at inventing realistic or interesting problems. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */