Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Fri, 29 Nov 2024 17:34:01 +0100
Organization: A noiseless patient Spider
Lines: 239
Message-ID: <vicqdp$15ium$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vi6sb1$148h7$1@paganini.bofh.team>
 <vi6uaj$3ve13$2@dont-email.me> <87plmfu2ub.fsf@nosuchdomain.example.com>
 <vi9jk4$gse4$1@dont-email.me> <vi9kng$gn4c$1@dont-email.me>
 <87frnbt9jn.fsf@nosuchdomain.example.com> <viaqh0$nm7q$1@dont-email.me>
 <877c8nt255.fsf@nosuchdomain.example.com> <viasv4$nm7q$2@dont-email.me>
 <vibr1l$vvjf$1@dont-email.me> <vic73f$1205f$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 29 Nov 2024 17:34:03 +0100 (CET)
Injection-Info: dont-email.me; posting-host="1cd76f73c030e28aa6d9843f10c4f882";
	logging-data="1231830"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19yMBT8UvXo7kmalQ9VbIx0HrgWXDejq7g="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:avHpc/kzHEtNLEFFo3AQWDJm0HQ=
Content-Language: en-GB
In-Reply-To: <vic73f$1205f$1@dont-email.me>
Bytes: 11636

On 29/11/2024 12:04, Bart wrote:
> On 29/11/2024 07:38, David Brown wrote:
>> On 29/11/2024 00:05, Bart wrote:
>>> On 28/11/2024 22:38, Keith Thompson wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>> On 28/11/2024 19:58, Keith Thompson wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>> [...]
>>>>>>> I think 'const' is confusing for similar reasons that VLAs can be 
>>>>>>> both
>>>>>>> confusing and awkward to implement.
>>>>>>>
>>>>>>> That's because both really apply to /types/, not directly to 
>>>>>>> variables.
>>>>>> Sure.  For example, given
>>>>>>       const int n = 42;
>>>>>> n is of type `const int`, and &n is of type `consts int*`.  Of course
>>>>>> that implies that n itself is const.
>>>>>
>>>>> But that is a separate thing. Suppose T was an alias for 'const 
>>>>> int'. Then:
>>>>>
>>>>>    T x;           // defines a readonly variable (which probably needs
>>>>>                   // initialising)
>>>>>    T* y;          // defines a variable pointer
>>>>>
>>>>> 'const' is out of the picture.
>>>>
>>>> You say T is an alias (what, a macro?) for 'const int', you show code
>>>> using T, and then you say "'const' is out of the picture".  If you have
>>>> a point, it escapes me.
>>>
>>> Well, can you see 'const' in my example? You can't tell x is readonly 
>>> by only looking at this.
>>>
>>>
>>>> Yes, and you seem determines to make it easier to get mixed up.
>>>
>>>
>>> C doesn't require any help from me for confusing features. The OP 
>>> said it was confusing and I tried to point out why it might be.
>>>
>>> Obviously you as C expert will never be confused. But there are lots 
>>> of less expert users of the language.
>>>
>>> I've just several minutes trying to figure why all these assignments 
>>> are invalid:
>>>
>>>      typedef int* T;
>>>
>>>      int  const x;
>>
>> That one is really simple - clearly "x" is declared "const", and so 
>> you can't assign to it later.
>>
>>>      T    const y;
>>
>> That one is equally simple - clearly "y" is declared "const", and so 
>> you can't assign to it later.
>>
>> That shows exactly why it can be a good idea to use "typedef", even 
>> for relatively simple things such as adding a pointer or qualifiers to 
>> the type.  I would not normally make a typedef just for a pointer, or 
>> just to add a "const" qualifier, but if the final type is complicated, 
>> it can make things clearer.  Really, it's just like breaking a 
>> complicated expression into parts with extra local variables to name 
>> them.
>>
>>>      int* const z;
>>>
>>
>> This one requires a little more thought, but it should be well within 
>> the capacity of any C programmer to see that "z" is declared "const".
> 
> These are similar examples:
> 
>      int * const z1;
>      int const * z2;
> 
>      z1=0;          // invalid
>      z2=0;          // valid
> 

Yes.  This is C course lesson 1 stuff.

The type here comes in two parts - the pointer, and the thing being 
pointed at (the "pointee", if that's a real word).  So there are two 
parts that could, independently, be qualified as "const" - thus it 
matters whether the "const" is before or after the asterisk.

I don't disagree that there are other ways to make a language syntax to 
specify types, or that some alternatives might be easier to follow than 
C (such as always left-to-right, or always right-to-left).

But cases like this are not hard, and it is not at all unreasonable to 
expect anyone who calls themselves a "C programmer" to handle those 
examples without a moment's thought.

And if you get it muddled, the chances are very high that the compiler 
will tell you when you try to compile the code (any compiler will 
complain about assigning to a const, not just ones with good static 
error checking).


> 
> 
> 
>>>      x=0;
>>>      y=0;
>>>      z=0;
>>>
>>> because I thought would behave differently, with 'const' being the 
>>> opposite side of '*' to the base-type.
>>>
>>
>> The "const" in each case clearly applies to the type of the declared 
>> variable.
>>
>>> I forgot that here it would be the right-most 'const' that controls 
>>> storage attributes of 'z'.
> 
> Both 'const' in my new examples are the the right-most one! Yet one 
> makes the immediate storage const and one doesn't. I guess then that 
> it's the right-most possible 'const' if it were to be used. In my 
> example,  that would follow the '*'.

You invented a rule (that the right-most "const" controls the variable), 
and it turned out to be wrong.  In hindsight, that should be totally 
obvious to you - if your rule had been true, there would be no way to 
specify a non-const pointer to const data, since the first "const" would 
also be the last one.

Instead, try to learn the rules of C, rather than making up incorrect 
rules and confusing yourself.

> 
>>> You will of course say that I'm the only person in the world who 
>>> could make that mistake.
>>>
>>
>> I certainly don't say you are the only person in the world who /could/ 
>> make that mistake.  But if we narrow it down to the C programmers who 
>> /would/ make such mistakes, you are in a much smaller group.
>>
>> There are two types of C programmers - those who like to declare 
>> variables "const" on a regular basis, and those who rarely if ever do 
>> (reserving "const" for things like "const int *" pointers).  Those 
>> that declare const variables, initialise them at the time, and would 
>> not be trying to assign them later.  Those who don't have much use of 
>> const variables, would not be writing such code in the first place.
>>
>> Basically, I'd only expect to see examples like that in the questions 
>> section of a beginner's book on C.  And I'd expect anyone who had read 
>> the preceding chapter to be able to answer it.
> 
> My original point was trying to address why 'const' as used in C might 
> be confusing. I was trying to compare how non-mutable variables are 
> designated in other languages. There it's a keyword that is part of the 
> declaration syntax, not the type syntax.
> 

C makes "const" part of the type - it is a type qualifier.  It is also 
possible for a language to make "constness" an attribute of the variable 
but not of the type.  The C language makes the design decision that 
variables don't get extra attributes - qualifiers like "const" and 
"volatile" must therefore by part of the type.  That simplifies many 
things in the language.  (That design decision is independent of the 
syntax used to specify types - it would apply even if C had used, say, 
"const * (const int)" to specify "const pointer to type const int".)

Some languages do have declaration keywords that determine the constness 
of the declared variable, yes.  I don't know if the constness of the 
variable is part of the variable's type or an extra attribute or 
========== REMAINDER OF ARTICLE TRUNCATED ==========