David Brown <david.brown@hesbynett.no> writes:

> On 28/10/2021 17:50, Meredith Montgomery wrote:
>> These seem legal declarations in C:
>>
>> const char msg[9] = "warming:";
>> char const msg[9] = "warming:";
>>
>> What's the difference between them?
>>
>
> Nothing.
>
> Both mean that the array is made of "const char" elements - after you
> have initialised the array, you can't change them.
>
>
> A lot of people prefer the "const on the left" arrangement :
>
> const int x = 123;
>
> It is very common to use this ordering - many programmers feel it is
> more natural.
>
>
> Some people prefer the "const on the right" arrangement (known as "east
> const") :
>
> int const x = 123;
>
> The argument there is that it is more consistent, especially in C++
> (which has a few other possible uses of the word "const").
>
>
>
> It is fair to say that the "east const" is more consistent when you have
> more complicated declarations involving pointers with "const" applied to
> different parts. That does not mean that it is the clearest way to
> write simple declarations, which are far more common. So opinions
> differ here. You have to learn to understand the placement options as
> you will see both when you read other people's code, and you have to
> decide for yourself which you choose in your own code (unless you are
> using a set of style guidelines that forces the decision on you).
>
>
> The general rule is "const applies to the thing just to the left of it,
> unless there is nothing to the left of it and it then applies to the
> thing to the right of it". This fits well with the usual best tactic
> for parsing most types - start from the right and work left.

Pretty useful guidance. Thank you. I will try that from now on.

You spoke of consistency above, but your paragraphs sometimes skip one
line, sometimes two lines, sometimes three lines. What's up with that?

:-)

On 29/10/2021 15:31, David Brown wrote:
> On 29/10/2021 12:30, Bart wrote:
>> On 29/10/2021 09:03, David Brown wrote:
>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>> These seem legal declarations in C:
>>>>
>>>>    const char msg[9] = "warming:";
>>>>    char const msg[9] = "warming:";
>>>>
>>>> What's the difference between them?
>>
>>> The general rule is "const applies to the thing just to the left of it,
>>> unless there is nothing to the left of it and it then applies to the
>>> thing to the right of it".
>> The trouble is the 'thing' will be just a token, not a complete type, so
>> here:
>>
>>    long const long x;
>
> And how /exactly/ do you think this kind of thing is helping someone
> learning the language? No one writes code like that, so it is simply
> not an issue.

They presumably do do so (even if it's indirectly via macros), otherwise
most alternatives for writing the same type would long have been
deprecated from the language, with tighter rules as to the placement and
number of 'const' attributes.

> If you are writing a compiler and want to be sure it is
> as standards-compliant as you can,

Think about why that might be necessary.

> you need to know about this sort of
> thing - no one else does.
>
> You seem to have an irresistible urge to spread your own confusions,

I like to give the unadorned facts. Have a look at my first post again.
I say exactly what C allows you to write. Knowing that type declarations
can be a free-for-all is handy when encountering anything unusual.

> and
> to highlight the worst possible complications of the language. It is as
> unhelpful for a poster like this OP as those who quote the details of
> standards, or go off on tangents about how they want to add weird
> extensions to their own compilers. How about just giving the guy some
> useful advice and general rules, rather than every obscure exception to
> those rules?
>
> This thread (not just your replies, but those from several others) is
> why comp.lang.c has a reputation for being useless to people looking for
> help with the C language.

Your advice to read declarations from right to left I think was not
helpful either, being incorrect except in the simplest cases involving
only * modifiers and associated consts.

On 29/10/2021 17:45, Bart wrote:
> On 29/10/2021 15:31, David Brown wrote:
>> On 29/10/2021 12:30, Bart wrote:
>>> On 29/10/2021 09:03, David Brown wrote:
>>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>>> These seem legal declarations in C:
>>>>>
>>>>>     const char msg[9] = "warming:";
>>>>>     char const msg[9] = "warming:";
>>>>>
>>>>> What's the difference between them?
>>>
>>>> The general rule is "const applies to the thing just to the left of it,
>>>> unless there is nothing to the left of it and it then applies to the
>>>> thing to the right of it".
>>> The trouble is the 'thing' will be just a token, not a complete type, so
>>> here:
>>>
>>>     long const long x;
>>
>> And how /exactly/ do you think this kind of thing is helping someone
>> learning the language?  No one writes code like that, so it is simply
>> not an issue.
>
> They presumably do do so (even if it's indirectly via macros), otherwise
> most alternatives for writing the same type would long have been
> deprecated from the language, with tighter rules as to the placement and
> number of 'const' attributes.
>

Why? What would be the advantages of deprecating it? It would make no
difference to people writing C, but mean extra checks would have to be
added to compliant compilers as well as changes to the grammar in the
standards document. And there may conceivably be some odd program with
code like this - perhaps something with a history so far back that it
used macros instead of typedefs and ended up with such results. All in
all, making such changes would be all effort and no gain.

>> If you are writing a compiler and want to be sure it is
>> as standards-compliant as you can,
>
> Think about why that might be necessary.
>
>> you need to know about this sort of
>> thing - no one else does.
>>
>> You seem to have an irresistible urge to spread your own confusions,
>
> I like to give the unadorned facts. Have a look at my first post again.
> I say exactly what C allows you to write. Knowing that type declarations
> can be a free-for-all is handy when encountering anything unusual.
>
>> and
>> to highlight the worst possible complications of the language.  It is as
>> unhelpful for a poster like this OP as those who quote the details of
>> standards, or go off on tangents about how they want to add weird
>> extensions to their own compilers.  How about just giving the guy some
>> useful advice and general rules, rather than every obscure exception to
>> those rules?
>>
>> This thread (not just your replies, but those from several others) is
>> why comp.lang.c has a reputation for being useless to people looking for
>> help with the C language.
>
> Your advice to read declarations from right to left I think was not
> helpful either, being incorrect except in the simplest cases involving
> only * modifiers and associated consts.
>

In other words, it applies fine to the large majority of declarations.
You can add "inside out" to it to cover more cases.

I understand that this is a simplification - but that's what people need
at the start.

On 29/10/2021 17:22, Meredith Montgomery wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>> These seem legal declarations in C:
>>>
>>> const char msg[9] = "warming:";
>>> char const msg[9] = "warming:";
>>>
>>> What's the difference between them?
>>>
>>
>> Nothing.
>>
>> Both mean that the array is made of "const char" elements - after you
>> have initialised the array, you can't change them.
>>
>>
>> A lot of people prefer the "const on the left" arrangement :
>>
>> const int x = 123;
>>
>> It is very common to use this ordering - many programmers feel it is
>> more natural.
>>
>>
>> Some people prefer the "const on the right" arrangement (known as "east
>> const") :
>>
>> int const x = 123;
>>
>> The argument there is that it is more consistent, especially in C++
>> (which has a few other possible uses of the word "const").
>>
>>
>>
>> It is fair to say that the "east const" is more consistent when you have
>> more complicated declarations involving pointers with "const" applied to
>> different parts. That does not mean that it is the clearest way to
>> write simple declarations, which are far more common. So opinions
>> differ here. You have to learn to understand the placement options as
>> you will see both when you read other people's code, and you have to
>> decide for yourself which you choose in your own code (unless you are
>> using a set of style guidelines that forces the decision on you).
>>
>>
>> The general rule is "const applies to the thing just to the left of it,
>> unless there is nothing to the left of it and it then applies to the
>> thing to the right of it". This fits well with the usual best tactic
>> for parsing most types - start from the right and work left.
>
> Pretty useful guidance. Thank you. I will try that from now on.
>
> You spoke of consistency above, but your paragraphs sometimes skip one
> line, sometimes two lines, sometimes three lines. What's up with that?
>
> :-)
>

It's to give you time to think and absorb the information underway!
Also, it gives a visual separation that is greater than I used for the
code snippets - so the spacing is intentional. (I know your question
wasn't very serious.)

David Brown <david.brown@hesbynett.no> writes:

> On 29/10/2021 17:22, Meredith Montgomery wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>> These seem legal declarations in C:
>>>>
>>>> const char msg[9] = "warming:";
>>>> char const msg[9] = "warming:";
>>>>
>>>> What's the difference between them?
>>>>
>>>
>>> Nothing.
>>>
>>> Both mean that the array is made of "const char" elements - after you
>>> have initialised the array, you can't change them.
>>>
>>>
>>> A lot of people prefer the "const on the left" arrangement :
>>>
>>> const int x = 123;
>>>
>>> It is very common to use this ordering - many programmers feel it is
>>> more natural.
>>>
>>>
>>> Some people prefer the "const on the right" arrangement (known as "east
>>> const") :
>>>
>>> int const x = 123;
>>>
>>> The argument there is that it is more consistent, especially in C++
>>> (which has a few other possible uses of the word "const").
>>>
>>>
>>>
>>> It is fair to say that the "east const" is more consistent when you have
>>> more complicated declarations involving pointers with "const" applied to
>>> different parts. That does not mean that it is the clearest way to
>>> write simple declarations, which are far more common. So opinions
>>> differ here. You have to learn to understand the placement options as
>>> you will see both when you read other people's code, and you have to
>>> decide for yourself which you choose in your own code (unless you are
>>> using a set of style guidelines that forces the decision on you).
>>>
>>>
>>> The general rule is "const applies to the thing just to the left of it,
>>> unless there is nothing to the left of it and it then applies to the
>>> thing to the right of it". This fits well with the usual best tactic
>>> for parsing most types - start from the right and work left.
>>
>> Pretty useful guidance. Thank you. I will try that from now on.
>>
>> You spoke of consistency above, but your paragraphs sometimes skip one
>> line, sometimes two lines, sometimes three lines. What's up with that?
>>
>> :-)
>>
>
> It's to give you time to think and absorb the information underway!
> Also, it gives a visual separation that is greater than I used for the
> code snippets - so the spacing is intentional. (I know your question
> wasn't very serious.)

It wasn't, yes, but that's because I thought there wasn't a special
reason. Now that I know there is, I'm impressed and a bit surprised, so
now I'm glad I asked.

Here's what I probably would have done.

--8<---------------cut here---------------start------------->8---
(*) Introduction

Lorem ipsum dolor...

(*) Now to your question specifically

Lorem...

(*) Taking stock or something

Lorem ipsum...
--8<---------------cut here---------------end--------------->8---

If you think about it, your style up there is a a bit too implicit. If
I'd like to give the reader some time to ponder, I would say that
explicitly --- dear reader, please take some time to ponder.

Having said that, I never cast the return of malloc. :-)

On 10/29/2021 6:30 PM, David Brown wrote:
> On 29/10/2021 17:45, Bart wrote:
>> On 29/10/2021 15:31, David Brown wrote:
>>> On 29/10/2021 12:30, Bart wrote:
>>>> On 29/10/2021 09:03, David Brown wrote:
>>>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>>>> These seem legal declarations in C:
>>>>>>
>>>>>>     const char msg[9] = "warming:";
>>>>>>     char const msg[9] = "warming:";
>>>>>>
>>>>>> What's the difference between them?
>>>>
>>>>> The general rule is "const applies to the thing just to the left of it,
>>>>> unless there is nothing to the left of it and it then applies to the
>>>>> thing to the right of it".
>>>> The trouble is the 'thing' will be just a token, not a complete type, so
>>>> here:
>>>>
>>>>     long const long x;
>>>
>>> And how /exactly/ do you think this kind of thing is helping someone
>>> learning the language?  No one writes code like that, so it is simply
>>> not an issue.
>>
>> They presumably do do so (even if it's indirectly via macros), otherwise
>> most alternatives for writing the same type would long have been
>> deprecated from the language, with tighter rules as to the placement and
>> number of 'const' attributes.
>>
>
> Why? What would be the advantages of deprecating it? It would make no
> difference to people writing C, but mean extra checks would have to be
> added to compliant compilers as well as changes to the grammar in the
> standards document. And there may conceivably be some odd program with
> code like this - perhaps something with a history so far back that it
> used macros instead of typedefs and ended up with such results. All in
> all, making such changes would be all effort and no gain.
>
>>> If you are writing a compiler and want to be sure it is
>>> as standards-compliant as you can,
>>
>> Think about why that might be necessary.
>>
>>> you need to know about this sort of
>>> thing - no one else does.
>>>
>>> You seem to have an irresistible urge to spread your own confusions,
>>
>> I like to give the unadorned facts. Have a look at my first post again.
>> I say exactly what C allows you to write. Knowing that type declarations
>> can be a free-for-all is handy when encountering anything unusual.
>>
>>> and
>>> to highlight the worst possible complications of the language.  It is as
>>> unhelpful for a poster like this OP as those who quote the details of
>>> standards, or go off on tangents about how they want to add weird
>>> extensions to their own compilers.  How about just giving the guy some
>>> useful advice and general rules, rather than every obscure exception to
>>> those rules?
>>>
>>> This thread (not just your replies, but those from several others) is
>>> why comp.lang.c has a reputation for being useless to people looking for
>>> help with the C language.
>>
>> Your advice to read declarations from right to left I think was not
>> helpful either, being incorrect except in the simplest cases involving
>> only * modifiers and associated consts.
>>
>
> In other words, it applies fine to the large majority of declarations.
> You can add "inside out" to it to cover more cases.
>
> I understand that this is a simplification - but that's what people need
> at the start.
>
>
>

Not sure about that, at least not this kind of simplification.
I think Bart made a good point, in noting that the right-to-left rule
does not work well in some case, notably with pointers to arrays, which
is something to be considered at any level of C knowledge.
So, as a first a simplification that can be wrong with some declaration
that, although unfriendly to the novice, can actually be found in real
code, runs the risk of being more confusing than helpful for the less
experienced.
The second problem is that when such less experienced happens to read
the standard's definition (which will happen at some point for any
serious programmer), they will have the problem that the simplification
is nowhere near the wording of the standard, so again risk of more
confusion than help.

From all the answers that have been given here, I think that one of
James Kuypers' (the one citing the standard's distinction between
'declaration-specifiers' and 'init-declarator-list') is the most useful,
because /that/ is how declarations work in C, plain and simple, even if
their description is not that simple.

On 29/10/2021 17:30, David Brown wrote:
> On 29/10/2021 17:45, Bart wrote:

>> They presumably do do so (even if it's indirectly via macros), otherwise
>> most alternatives for writing the same type would long have been
>> deprecated from the language, with tighter rules as to the placement and
>> number of 'const' attributes.
>>
>
> Why? What would be the advantages of deprecating it? It would make no
> difference to people writing C, but mean extra checks would have to be
> added to compliant compilers as well as changes to the grammar in the
> standards document.

It actually makes compilation simpler, if you knew for example that the
pattern was always:

[const] [unsigned/signed] [long [long] / short] int

As to the advantages of deprecating it, the behaviour of most compilers,
using default options, is to be incredibly lax about things that I
consider irresponsibly dangerous.

So people continue their bad coding habits, because they are not like
you in devising a strict dialect of the language, and implementing that
dialect via sets of compiler options.

> And there may conceivably be some odd program with
> code like this

Or maybe you write the code by accident. Then you are either puzzled why
it doesn't work, or don't notice, until it puzzles someone else.

- perhaps something with a history so far back that it
> used macros instead of typedefs and ended up with such results. All in
> all, making such changes would be all effort and no gain.

It can be easier than you think. My own compiler disallows many things I
consider unacceptable. But for the purposes of compiling legacy code, I
require one special option to be specified.

Manfred <noname@add.invalid> writes:

> On 10/29/2021 6:30 PM, David Brown wrote:
>> On 29/10/2021 17:45, Bart wrote:
>>> On 29/10/2021 15:31, David Brown wrote:
>>>> On 29/10/2021 12:30, Bart wrote:
>>>>> On 29/10/2021 09:03, David Brown wrote:
>>>>>> On 28/10/2021 17:50, Meredith Montgomery wrote:
>>>>>>> These seem legal declarations in C:
>>>>>>>
>>>>>>> const char msg[9] = "warming:";
>>>>>>> char const msg[9] = "warming:";
>>>>>>>
>>>>>>> What's the difference between them?

[...]

>>> Your advice to read declarations from right to left I think was not
>>> helpful either, being incorrect except in the simplest cases involving
>>> only * modifiers and associated consts.
>>>
>> In other words, it applies fine to the large majority of
>> declarations. You can add "inside out" to it to cover more cases. I
>> understand that this is a simplification - but that's what people
>> need at the start.
>
> Not sure about that, at least not this kind of simplification. I
> think Bart made a good point, in noting that the right-to-left rule
> does not work well in some case, notably with pointers to arrays,
> which is something to be considered at any level of C knowledge. So,
> as a first a simplification that can be wrong with some declaration
> that, although unfriendly to the novice, can actually be found in real
> code, runs the risk of being more confusing than helpful for the less
> experienced.
>
> The second problem is that when such less experienced happens to read
> the standard's definition (which will happen at some point for any
> serious programmer), they will have the problem that the
> simplification is nowhere near the wording of the standard, so again
> risk of more confusion than help.
>
> From all the answers that have been given here, I think that one of
> James Kuypers' (the one citing the standard's distinction between
> 'declaration-specifiers' and 'init-declarator-list') is the most
> useful, because /that/ is how declarations work in C, plain and
> simple, even if their description is not that simple.

It's really education we're talking about here. Education is not quite
a scientific area; it's a philosophical one in the Bertrand Russell
sense of philosophy: if there were a clear answer to how to do it, it'd
be called science. (See the first few pages of his ``A History of
Western Philosophy''.)

Because we don't know what is the right approach, we should more or less
provide them all. More or less, of course. And it is a very good idea
to present to students your opinion such as --- this is the right
approach **for sure** and there are other silly approaches too because
some people are too blind to see.

Consider this very thread. A novice is looking at this and getting a
clear picture of the cloud that education in this area is. (It's like
that in every area, actually.) That's (evidently) a fact --- locally at
the very least.

One of the great friends of students is moving-ahead. You realize
you've got an education when you look back, but to look back you must
move ahead. So it is a good idea to come up with a modus operandi, even
if it's broken. This is an important piece of the scientific method:
come up with a hypothesis and stress it until it breaks.

But, of course, if the student can't understand the hypothesis (because
it's too complex), then it might be a useless one. There are multiple
levels of students --- there are researcher-students, students-students,
children-students.

Manfred <noname@add.invalid> writes:

> On 10/29/2021 6:30 PM, David Brown wrote:

>> In other words, it applies fine to the large majority of declarations.
>> You can add "inside out" to it to cover more cases.
>>
>> I understand that this is a simplification - but that's what people need
>> at the start.
>
> Not sure about that, at least not this kind of simplification.
> I think Bart made a good point, in noting that the right-to-left rule
> does not work well in some case, notably with pointers to arrays,
> which is something to be considered at any level of C knowledge.

The simple rule goes wrong for even simpler cases:

int a[3][5];
double f(double);

If you start at the name, the rule is to read to the right, and only
switch to reading left when you have to (which needs to be tied down).
This is because []s and ()s bind more tightly than *:

int *a[10];
>>>>> "a is an array of 10"
<<<<< "pointers to int"

The reference to "inside out" means you need to finish off parentheses
before moving outside:

int (*a)[10];
<< "a is a pointer to"
>>>>> "an array of 10"
<<<< "int"

Mind you, I don't usually do it this way. I read the declarator (the
part that decorates the name) like I do expressions. I don't vocalise

*a[10]

in an expression like

*a[10] = 42

I know the precedence and associativity so I know this is indexing 'a' and
dereferencing the result, as opposed to

(*a)[10] = 42

which dereferences a pointer and indexes the result.

--
Ben.