Path: ...!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: Fri, 29 Nov 2024 17:28:22 -0800 Organization: None to speak of Lines: 150 Message-ID: <87ttbpqzm1.fsf@nosuchdomain.example.com> References: <87plmfu2ub.fsf@nosuchdomain.example.com> <87frnbt9jn.fsf@nosuchdomain.example.com> <877c8nt255.fsf@nosuchdomain.example.com> <20241129142810.00007920@yahoo.com> <20241129161517.000010b8@yahoo.com> <87mshhsrr0.fsf@nosuchdomain.example.com> <8734j9sj0f.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 30 Nov 2024 02:28:23 +0100 (CET) Injection-Info: dont-email.me; posting-host="d28f02e76a6c2d00a69abdf93e7df1d2"; logging-data="1354134"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/h2lA2J0cgU3fwPza0coEe" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:n9J0iH3LISmyDn00iP45PMtQs/0= sha1:BtxDxlpJblpgVk2WN0UwD99tTXw= Bytes: 7886 Bart writes: > On 29/11/2024 23:44, Keith Thompson wrote: >> Bart writes: >>> On 29/11/2024 20:35, Keith Thompson wrote: >>> (So it would have a different type from E declared on in the same >>> declaration: >>> >>> int D[3][4][5], E; >>> >>> ? In that case tell that to David Brown!) >> Yes, of course D and E have different types. I'm certain he's >> aware of that. > > Apparently the quibble is about the meaning of 'totally different'. I > would have thought that 'incompatible' would have covered it. No, "incompatible" has a specific meaning in C which is unrelated to what we're talking about. > But it looks like, for the sake of argument, types aren't 'totally' > different if they have even the slightest point of similarity. So an > 'int' type, and a bloody great function, not even a real type, must be > considered somewhat identical if the latter happens to returns an int? I won't try to speak for David. I speculated about what he meant by what was I presume was a throwaware phrase used in a specific context. (I probably read it at the time, but I don't remember.) I will not discuss the meaning of "totally different types" any further. > In my language which you despise but provides a great perspective, > variables declared in the same declaration have 100% the same type. If > they are even 1% different, then that is a separate type and they need > their own declarations. They are no gradations! You claim that I "despise" your language. That is a lie. I'm simply not interested in it. If I were, I'd be glad to discuss it in, say, comp.lang.misc. It is a fact that a C declaration can declare multiple entities, possibly of different types, but with restrictions on which types can be combined. I have not expressed an opinion on whether I think that's a good idea. It's a feature that I rarely take advantage of. >> What "range of types" do you think D can have? > > If DB is talking about the type of D[i][j][k], then it is also > necessary to consider the types of D, D[i] etc. That's why it's not > useful to talk about anything other than the type of the value stored > in D (and in C, before D is used in any expression). The definition of D was : int D[3][4][5]; I don't know whether DB was talking about "the type of D[i][j][k]" (which is obviously int, BTW). I was talking about the type of D. I've already told you what type the object D has, and the two types the expression D can have depending on context. I note your refusal to answer. >>>> Would you write "const int F();"? Or would you omit the "const"? How >>>> does the fact that "const" is allowed inconvenience you? >>> >>> It's another point of confusion. In my language I don't treat function >>> declarations like variable declarations. A function is not a >>> variable. There is no data storage associated with it. >> In C, declarations can declare objects, functions, types, etc. > > Actually types would be another category, that can also start off > looking like a variable declaration. Yes, I mentioned types. Your point? >> to see how your language is relevant. > > Because it's confusing in C. The perspective of a quite different > syntax /for the same class of language/ makes that extra clear to me. > > In C all declarations are based around the syntax as used for > variables, even function definitions. Yes, C declarations mostly follow a "declaration follows use" pattern. Everyone knows that. Many, perhaps most, C programmers don't particularly like it, but spend little time complaining about it. I have yet to see you make an interesting point about that fact. >>> In C it is unfortunate, as it makes it hard to trivially distinguish a >>> function declaration (or the start of a function definition) from a >>> variable declaration. >> It's not as hard as you insist on pretending it is. A function >> declaration includes a pair of parentheses, either empty or >> containing a list of parameters or parameter types. > > Yes it is, I'm not pretending at all. > > Perhaps you can post a trivial bit of C code which reads in C source > code and shows the first lines of all the function definitions, not > prototypes nor function pointers. It can assume that each starts at > the beginning of a line. No. It's straightforward for an experienced C programmer looking at code that's not deliberately obscure. A program that can do the same thing reliably would have to include a C preprocessor and parser. It's obvious that : int foo(int); is intended to be a function declaration, but if there's a visible macro definition : #define foo(n) foo then it's an object declaration. No "trivial bit of C code" will handle that kind of thing. No doubt you'll take that as evidence that C Is Bad rather than an argument against writing bad code. And I was talking about function declarations, not function definitions. The goalposts were fine where they were. > However each may start with a user-defined type or there may be a > macros in any positions. > > I can tell that in my syntax, function definitions start with a line > like this ([...] means optional; | separates choices): > > ['global'|'export'] 'func'|'proc' name ... > > Which one do you think would be easier? (Function declarations are > generally not used.) I don't care. Yes, languages than C can have better declaration syntax than C does (where "better" is clearly subjective). Perhaps yours does. How many times do I have to acknowledge that before you'll stop harping on it? >> Function declarations outside header files are valid, but tend to be >> rare in well-written C code. > > Function declarations are everywhere. They are usually needed for > static function otherwise you will have hundreds of function > definitions that must be written and maintained in a specific order. I acknowledged elsewhere that I forgot about declarations of static functions. (Hundreds of function definitions in a single source file seem unlikely.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */