Re: question about linker

bart <bc@freeuk.com> writes:

On 14/12/2024 22:22, Keith Thompson wrote:

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.

>
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 <stdio.h>, <stddef.h>; // ???

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 */