Re: question about linker

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.

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?

I don't care about it. I just wondered why not since such lists are allowed elsewhere.

[...]
 

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; this one is starting to look like a hack:
   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?
Because in that case, they are not needed in S1, but the one after S2's expansion will still be superfluous.

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?

As I said, the whole thing is starting to look like a hack just so you
/don't/ end up with sequences of semicolons.

[...]
 

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]

<example of what a more consistent syntax looks like snipped>