These seem legal declarations in C:

const char msg[9] = "warming:";
char const msg[9] = "warming:";

What's the difference between them?

(*) Note to self

When I tried changing that array, the compiler did not let me to ---
with either declaration. (So it appears there is no *effective*
difference.)

%cat msg.c
#include <stdio.h>

int main(void) {

char const msg[9] = "warming:";
msg[0]= 'f';
printf("%s\n", msg);

} %make msg
gcc msg.c -o msg
msg.c: In function 'main':
msg.c:6:9: error: assignment of read-only location 'msg[0]'
6 | msg[0]= 'f';
| ^
make: *** [<builtin>: msg] Error 1
%

Meredith Montgomery <mmontgomery@levado.to> writes:
>const char msg[9] = "warming:";
>char const msg[9] = "warming:";
>What's the difference between them?

After,

typedef void * pointer;
const pointer p;

. "p" is a /const/ pointer, /not/ a pointer to const!
One cannot simple "insert the typedef", which would yield:

const pointer p; -->
const void * p;

, "const void * p;" would means that "p" is a "pointer to
const", but "const pointer p;" really means that p is a
"const pointer to mutable".

. This is made more clear for humans when written as

pointer const p;

, although in C "const pointer p;" and "pointer const p;"
are equivalent.

~

When one uses a "read-from-right-to -eft rule",

char const * const p;

is more natural, because, when we reverse the text
word-by-word, we get

; p const * const char

, pronounce:

; p const * const char
er, p is a const pointer to a const char object

~

The C grammar:

<declaration>::=<declaration-specifiers>[<init-declarator-list>]";".
<declaration-specifiers>::=<type-qualifier>[<declaration-specifiers>].
<type-qualifier>::="const"|"restrict"|"volatile".

~

Thanks go to Dan Sacks for ideas used in this post.

Supersedes: <const-20211028171419@ram.dialup.fu-berlin.de>
[corrected typos]

Meredith Montgomery <mmontgomery@levado.to> writes:
>const char msg[9] = "warming:";
>char const msg[9] = "warming:";
>What's the difference between them?

After,

typedef void * pointer;
const pointer p;

. "p" is a /const/ pointer, /not/ a pointer to const!
One cannot simple "insert the typedef", which would yield:

const pointer p; -->
const void * p;

, "const void * p;" would mean that "p" is a "pointer to
const", but "const pointer p;" really means that p is a
"const pointer to mutable".

. This is made more clear for humans when written as

pointer const p;

, although in C "const pointer p;" and "pointer const p;"
are equivalent.

~

When one uses a "read-from-right-to-left rule",

char const * const p;

is more natural, because, when we reverse the text
word-by-word, we get

; p const * const char

, pronounce:

; p const * const char
er, p is a const pointer to a const char object

~

The C grammar:

<declaration>::=<declaration-specifiers>[<init-declarator-list>]";".
<declaration-specifiers>::=<type-qualifier>[<declaration-specifiers>].
<type-qualifier>::="const"|"restrict"|"volatile".

.

~

Thanks go to Dan Sacks for ideas used in this post.

On 28/10/2021 16: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?

There is no difference. You can even write:

const char const msg[9];

'const' (as well as short, int, long, float, double, even static and
typedef) can occur anywhere, in any combination, in the declaration of a
base type (what goes on the left before the first variable).

'const' can also be repeated any number of times:

char const const const const const const msg[9]

if you want to be certain that msg is constant!

However when applied to a pointer, then it must go after *.

On 10/28/21 11:50 AM, 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?
>
> (*) Note to self
>
> When I tried changing that array, the compiler did not let me to ---
> with either declaration. (So it appears there is no *effective*
> difference.)
>
> %cat msg.c
> #include <stdio.h>
>
> int main(void) {
>
> char const msg[9] = "warming:";
> msg[0]= 'f';
> printf("%s\n", msg);
>
> }
> %make msg
> gcc msg.c -o msg
> msg.c: In function 'main':
> msg.c:6:9: error: assignment of read-only location 'msg[0]'
> 6 | msg[0]= 'f';
> | ^
> make: *** [<builtin>: msg] Error 1
> %
>

"const" is a type qualifier. "char" is a type specifier. Both are
members of the larger category called "declaration specifiers". If you
have a string of declaration specifiers, they can occur in any order you
like, without any change of meaning.

On Thursday, October 28, 2021 at 12:26:09 PM UTC-4, Bart wrote:
....
> 'const' (as well as short, int, long, float, double, even static and
> typedef) can occur anywhere, in any combination, in the declaration of a
> base type (what goes on the left before the first variable).
....
> However when applied to a pointer, then it must go after *.

const char * p
char * const q;
char const * const r;

are all permitted. p is a pointer to const char. q is a const pointer to char. r is a const pointer to const char.

Le 28/10/2021 à 19:10, james...@alumni.caltech.edu a écrit :
> On Thursday, October 28, 2021 at 12:26:09 PM UTC-4, Bart wrote:
> ...
>> 'const' (as well as short, int, long, float, double, even static and
>> typedef) can occur anywhere, in any combination, in the declaration of a
>> base type (what goes on the left before the first variable).
> ...
>> However when applied to a pointer, then it must go after *.
>
> const char * p
> char * const q;
> char const * const r;
>
> are all permitted. p is a pointer to const char. q is a const pointer to char. r is a const pointer to const char.

Yes indeed!
With pointer declarations, 'const' has a different meaning depending on
where it is located relative to '*', as you showed.

On Thursday, October 28, 2021 at 1:26:09 PM UTC-3, Bart wrote:
> On 28/10/2021 16: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?
> There is no difference. You can even write:
>
> const char const msg[9];
>
>
> 'const' (as well as short, int, long, float, double, even static and
> typedef) can occur anywhere, in any combination, in the declaration of a
> base type (what goes on the left before the first variable).
>
> 'const' can also be repeated any number of times:
>
> char const const const const const const msg[9]

We can also add as many parentheses as we like.
char const const const const const const ((((((msg))))))[9];
:D

On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
....
> > 'const' (as well as short, int, long, float, double, even static and
> > typedef) can occur anywhere, in any combination, in the declaration of a
> > base type (what goes on the left before the first variable).

I also have a new definition for typedef considering how it works.

We use to say typedef is a alias for a type name.

But here ,

typedef int Int;
typedef unsigned Int T; //error

Int does not work as a alias for int.

So my definition is:
when we put typedef in a declaration we declare a variable that has no
storage.

When we use this variable is the same of using typeof(variable) but
we write just the variable name.
Int x;
So typedef is more like "use the same type of that variable here".

considering this.... I was also considering to use typedef to define constants

typedef double pi = 3.14;
or
valuedef double pi = 3.14;

pi is a non-storage variable, but instead of copying its type
we copy its initialization value.

double x = pi;

On 28/10/2021 21:18, Thiago Adams wrote:
> On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> ...
>>> 'const' (as well as short, int, long, float, double, even static and
>>> typedef) can occur anywhere, in any combination, in the declaration of a
>>> base type (what goes on the left before the first variable).
>
> I also have a new definition for typedef considering how it works.
>
> We use to say typedef is a alias for a type name.
>
> But here ,
>
> typedef int Int;
> typedef unsigned Int T; //error
>
> Int does not work as a alias for int.

I think this is reasonable behavour. To make it work as you want, as an
alias for the 'int' /token/, then it can be done as:

#define Int int

For a composite type like 'int long long', it must be a valid
combination of those tokens. The alias 'T' may be defined internally as
a complete type 'signed long long int'.

You can't then modify it as 'unsigned signed long long int' even if you
could sort out the parsing.

For example, you can't do 'unsigned int32_t'.

>
> So my definition is:
> when we put typedef in a declaration we declare a variable that has no
> storage.

I can never remember how typedef works, and have to pretend that it is
'static', and I'm declaring a normal variable name.

> When we use this variable is the same of using typeof(variable) but
> we write just the variable name.
> Int x;
> So typedef is more like "use the same type of that variable here".
>
> considering this.... I was also considering to use typedef to define constants
>
> typedef double pi = 3.14;
> or
> valuedef double pi = 3.14;
>
> pi is a non-storage variable, but instead of copying its type
> we copy its initialization value.

I tried something like that. I couldn't use 'const' as that was taken; I
used 'constant':

constant int a = 1233;
constant double b = a/10.0;

printf("%d\n", a);
printf("%f\n", b);

This could be tweaked to infer the type from the expression.

On Thursday, October 28, 2021 at 5:35:36 PM UTC-3, Bart wrote:
> On 28/10/2021 21:18, Thiago Adams wrote:
> > On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> > ...
> >>> 'const' (as well as short, int, long, float, double, even static and
> >>> typedef) can occur anywhere, in any combination, in the declaration of a
> >>> base type (what goes on the left before the first variable).
> >
> > I also have a new definition for typedef considering how it works.
> >
> > We use to say typedef is a alias for a type name.
> >
> > But here ,
> >
> > typedef int Int;
> > typedef unsigned Int T; //error
> >
> > Int does not work as a alias for int.
> I think this is reasonable behavour. To make it work as you want, as an
> alias for the 'int' /token/, then it can be done as:
>
> #define Int int
>
> For a composite type like 'int long long', it must be a valid
> combination of those tokens. The alias 'T' may be defined internally as
> a complete type 'signed long long int'.
>
> You can't then modify it as 'unsigned signed long long int' even if you
> could sort out the parsing.
>
> For example, you can't do 'unsigned int32_t'.
> >
> > So my definition is:
> > when we put typedef in a declaration we declare a variable that has no
> > storage.
> I can never remember how typedef works, and have to pretend that it is
> 'static', and I'm declaring a normal variable name.
> > When we use this variable is the same of using typeof(variable) but
> > we write just the variable name.
> > Int x;
> > So typedef is more like "use the same type of that variable here".
> >
> > considering this.... I was also considering to use typedef to define constants
> >
> > typedef double pi = 3.14;
> > or
> > valuedef double pi = 3.14;
> >
> > pi is a non-storage variable, but instead of copying its type
> > we copy its initialization value.
> I tried something like that. I couldn't use 'const' as that was taken; I
> used 'constant':
>
> constant int a = 1233;
> constant double b = a/10.0;
>
> printf("%d\n", a);
> printf("%f\n", b);
>
> This could be tweaked to infer the type from the expression.

and because there is no storage we cannot take &a or &b.
BUT I think there is a hidden variable instantiated (just like compound literals)

For instance this is C99.

struct X { int i; };
void F(struct X* x) {}
struct X c = { . i = 1 };
int main() {
F(& (struct X) {.i = 1}); //variable is created
F(&c);
}

in this C99 sample c HAS storage. it exists.
Now lets consider we have this "constant".

struct X { int i; };
void F(struct X* x) {}
constant struct X c = { . i = 1 }; //no storage

int main() {
F(& (struct X) {.i = 1});
F(&c); //what happens here?
}

When we call F(&c) some variable should be instantiated.?

At the end it could work as enumerators work today

enum { A = 1 };
void F(int* i) {}
void F2(int i) {}
int main() {
F(&A); //error: lvalue required as unary '&' operand
F2(A); //OK
}

sometimes a local variable would be created, except for int double etc..

On Thursday, October 28, 2021 at 5:57:38 PM UTC-3, Thiago Adams wrote:
> On Thursday, October 28, 2021 at 5:35:36 PM UTC-3, Bart wrote:
> > On 28/10/2021 21:18, Thiago Adams wrote:
> > > On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> > > ...
> > >>> 'const' (as well as short, int, long, float, double, even static and
> > >>> typedef) can occur anywhere, in any combination, in the declaration of a
> > >>> base type (what goes on the left before the first variable).
> > >
> > > I also have a new definition for typedef considering how it works.
> > >
> > > We use to say typedef is a alias for a type name.
> > >
> > > But here ,
> > >
> > > typedef int Int;
> > > typedef unsigned Int T; //error
> > >
> > > Int does not work as a alias for int.
> > I think this is reasonable behavour. To make it work as you want, as an
> > alias for the 'int' /token/, then it can be done as:
> >
> > #define Int int
> >
> > For a composite type like 'int long long', it must be a valid
> > combination of those tokens. The alias 'T' may be defined internally as
> > a complete type 'signed long long int'.
> >
> > You can't then modify it as 'unsigned signed long long int' even if you
> > could sort out the parsing.
> >
> > For example, you can't do 'unsigned int32_t'.
> > >
> > > So my definition is:
> > > when we put typedef in a declaration we declare a variable that has no
> > > storage.
> > I can never remember how typedef works, and have to pretend that it is
> > 'static', and I'm declaring a normal variable name.
> > > When we use this variable is the same of using typeof(variable) but
> > > we write just the variable name.
> > > Int x;
> > > So typedef is more like "use the same type of that variable here".
> > >
> > > considering this.... I was also considering to use typedef to define constants
> > >
> > > typedef double pi = 3.14;
> > > or
> > > valuedef double pi = 3.14;
> > >
> > > pi is a non-storage variable, but instead of copying its type
> > > we copy its initialization value.
> > I tried something like that. I couldn't use 'const' as that was taken; I
> > used 'constant':
> >
> > constant int a = 1233;
> > constant double b = a/10.0;
> >
> > printf("%d\n", a);
> > printf("%f\n", b);
> >
> > This could be tweaked to infer the type from the expression.
> and because there is no storage we cannot take &a or &b.
> BUT I think there is a hidden variable instantiated (just like compound literals)
>
> For instance this is C99.
>
> struct X { int i; };
> void F(struct X* x) {}
> struct X c = { . i = 1 };
> int main() {
> F(& (struct X) {.i = 1}); //variable is created
> F(&c);
> }
>
> in this C99 sample c HAS storage. it exists.
> Now lets consider we have this "constant".
>
> struct X { int i; };
> void F(struct X* x) {}
> constant struct X c = { . i = 1 }; //no storage
>
> int main() {
> F(& (struct X) {.i = 1});
> F(&c); //what happens here?
> }
>
> When we call F(&c) some variable should be instantiated.?
>
> At the end it could work as enumerators work today
>
> enum { A = 1 };
> void F(int* i) {}
> void F2(int i) {}
> int main() {
> F(&A); //error: lvalue required as unary '&' operand
> F2(A); //OK
> }
>
> sometimes a local variable would be created, except for int double etc..

The reason why this features does not exist today may be because for complex
types we can create a const variable and reuse it.
and use defines for int double etc.

Thiago Adams <thiago.adams@gmail.com> writes:

> On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> ...
>> > 'const' (as well as short, int, long, float, double, even static and
>> > typedef) can occur anywhere, in any combination, in the declaration of a
>> > base type (what goes on the left before the first variable).
>
> I also have a new definition for typedef considering how it works.
>
> We use to say typedef is a alias for a type name.

"We"? The standard doesn't. It says the declaration defines a "typedef
name". I agree it's handy to think of it as an alias, but you have to
take care with analogies in technical situations.

> But here ,
>
> typedef int Int;
> typedef unsigned Int T; //error
>
> Int does not work as a alias for int.

An alias does not work in all contexts. I may be know as Shorty down
the club, but I can't put that on my passport. Sometimes the "proper"
name is needed.

> So my definition is:
> when we put typedef in a declaration we declare a variable that has no
> storage.

Well typedef is, syntactically, a storage class specifier like extern,
static and register, so I can see why you might prefer that analogy.

--
Ben.

On 28/10/2021 22:07, Thiago Adams wrote:
> On Thursday, October 28, 2021 at 5:57:38 PM UTC-3, Thiago Adams wrote:

>> in this C99 sample c HAS storage. it exists.
>> Now lets consider we have this "constant".
>>
>> struct X { int i; };
>> void F(struct X* x) {}
>> constant struct X c = { . i = 1 }; //no storage
>>
>> int main() {
>> F(& (struct X) {.i = 1});
>> F(&c); //what happens here?
>> }
>>
>> When we call F(&c) some variable should be instantiated.?
>>
>> At the end it could work as enumerators work today
>>
>> enum { A = 1 };
>> void F(int* i) {}
>> void F2(int i) {}
>> int main() {
>> F(&A); //error: lvalue required as unary '&' operand
>> F2(A); //OK
>> }
>>
>> sometimes a local variable would be created, except for int double etc..
>
> The reason why this features does not exist today may be because for complex
> types we can create a const variable and reuse it.
> and use defines for int double etc.

Below is a summary, in the first 3 Y/N columns, of the three different
ways C has to create named constants.

It's set up so that a Y response is the more desirable.

Here, enums tick nearly all the boxes, so that it is odd that #define
and const T seem more popular. But then, 'enum' was really intended for
other purposes (defining related names with incrementing values), so it
might itself seem odd to use it arbitrarily.

My 'constant' feature ticks all the boxes plus it doesn't look weird to use.

Characteristic #define const T enum 'constant'

Normal scope? N Y Y Y
Any numeric type? Y Y N Y
Avoids storage (5) Y N (3) Y Y
Use in non-VLA bounds Y N Y Y
Won't create a VLA? Y N Y Y
Use in static array bounds Y N Y Y
Use in switch-case labels Y N Y Y
Evaluate once (1) N Y Y Y
Prohibit & address-of Y N Y Y
Prohibit Pass by ref Y N Y Y
Impossible to modify? Y N (2) Y Y
Reduce const exprs? Y ? (3) Y Y
Unambiguous meaning (4) N Y Y Y

(1) With #define A ((B+C)*D) etc, at each place A is used, it will
expand that expression, and need to parse it and reduce, possibly 100s
of times

(2) It's possible to modify via casts

(3) Depends on compiler's optimisation abilities

(4) With #define, using the same ((B+C)*D) example each time A is
expanded, it will use whatever B, C, D names are in scope at that point,
potentially generating a different value of A each time.

(5) Apart from immediate operands, some hardware may require storage
for certain float operands for example. But this is not accessible to C
programs.

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, October 28, 2021 at 4:56:18 PM UTC-3, Thiago Adams wrote:
> ...
>> > 'const' (as well as short, int, long, float, double, even static and
>> > typedef) can occur anywhere, in any combination, in the declaration of a
>> > base type (what goes on the left before the first variable).
>
> I also have a new definition for typedef considering how it works.
>
> We use to say typedef is a alias for a type name.
>
> But here ,
>
> typedef int Int;
> typedef unsigned Int T; //error
>
> Int does not work as a alias for int.

Yes, it absolutely does. Given your first declaration, `Int` is an
alias for the *type* `int`, not for the *keyword* `int`. It's not a
macro, and it doesn't act like one.

The `unsigned` keyword can only be used as the syntax allows, and the
syntax doesn't allow it to be used with a typedef name. The `unsigned`
keyword can be used by itself as a type name, or along with the `char`,
`short`, `int`, and/or `long` keywords, as defined in N1570 6.7.2.

> So my definition is:
> when we put typedef in a declaration we declare a variable that has no
> storage.

No, that's not what it does. It doesn't declare a variable at all, with
or without storage, unless you stretch the meaning of "variable" almost
beyond recognition. (Note that the C standard doesn't use the term
"variable".). Rather, the `typedef` keyword is treated as a storage
class specifier for syntactic convenience.

> When we use this variable is the same of using typeof(variable) but
> we write just the variable name.
> Int x;
> So typedef is more like "use the same type of that variable here".
>
> considering this.... I was also considering to use typedef to define constants
>
> typedef double pi = 3.14;
> or
> valuedef double pi = 3.14;
>
> pi is a non-storage variable, but instead of copying its type
> we copy its initialization value.
>
> double x = pi;

That's more or less what `constexpr` does in C++, and what `const`
*almost* does in C. Using `typedef` for this would not in my opinion
make sense.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Thiago Adams <thiago.adams@gmail.com> writes:
> On Thursday, October 28, 2021 at 5:57:38 PM UTC-3, Thiago Adams wrote:
[...]
>> At the end it could work as enumerators work today
>>
>> enum { A = 1 };
>> void F(int* i) {}
>> void F2(int i) {}
>> int main() {
>> F(&A); //error: lvalue required as unary '&' operand
>> F2(A); //OK
>> }
>>
>> sometimes a local variable would be created, except for int double etc..
>
> The reason why this features does not exist today may be because for complex
> types we can create a const variable and reuse it.
> and use defines for int double etc.

C's "const" keyword does not mean "constant", and it never has. Of
course the spelling is derived from the English word "constant", which
can cause some understandable confusion.

A *constant expression* is one that can be evaluated at compile time.
A *constant* is a literal.

The keyword "const" might more accurately have been spelled "readonly".
If a name is const-qualified, it means that the named object cannot be
modified via that name. Defining something as "const" never makes
its name a constant expression.

C++ added a special case, so that for example
const int n = 42;
makes the expression n a constant expression (though n is still an
object whose address can be taken). Later, C++ added the "constexpr"
keyword (like "const" but it requires the initializer to be constant),
which in my opinion would have been a better choice for this special
case.

Note that this:
const time_t now = time(NULL);
is perfectly legal; the expression t cannot even in principle be
evaluated at compile time. (`constexpr time_t now = time(NULL);`
is invalid in C++.)

I wouldn't mind seeing a future version of C adopt something like C++'s
"constexpr" -- *without* changing the current meaning of "const".

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> I wouldn't mind seeing a future version of C adopt something like C++'s
> "constexpr" -- *without* changing the current meaning of "const".

It's been proposed:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2851.pdf

--
Ben.

Bart <bc@freeuk.com> writes:

> On 28/10/2021 16: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?
>
> There is no difference. You can even write:
>
> const char const msg[9];
>
>
> 'const' (as well as short, int, long, float, double, even static and
> typedef) can occur anywhere, in any combination, in the declaration of
> a base type (what goes on the left before the first variable).
>
> 'const' can also be repeated any number of times:
>
> char const const const const const const msg[9]
>
> if you want to be certain that msg is constant!
>
> However when applied to a pointer, then it must go after *.

Very interesting. Thank you so much for this.

"james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:

> On Thursday, October 28, 2021 at 12:26:09 PM UTC-4, Bart wrote:
> ...
>> 'const' (as well as short, int, long, float, double, even static and
>> typedef) can occur anywhere, in any combination, in the declaration of a
>> base type (what goes on the left before the first variable).
> ...
>> However when applied to a pointer, then it must go after *.
>
> const char * p
> char * const q;
> char const * const r;
>
> are all permitted. p is a pointer to const char. q is a const pointer
> to char. r is a const pointer to const char.

So the order does make a difference here. I mean

char const * r1

is not the same

char const * const r2

because r2 cannot point somewhere else but r1 can.

Thank you.

(*) So, I wrote this to check

#include <stdio.h>

int main()
{ const char c1 = 'x';
const char c2 = 'y';

const char* r1 = &c1;
const char* const r2 = &c1;

printf("r1 = %c, r2 = %c\n", *r1, *r2);

r1 = &c2;
/* r2 = &c2; */ /* cant do this */
printf("r1 = %c, r2 = %c\n", *r1, *r2);

return 0;
}

(*) What have I learned here as well?

When we declare something to be const we also have to define it in the
statement. IOW, I cannot separate declaration and definition of a const
thing. This makes sense --- if I can assign a const-thing, how would
the compiler keep me from changing it? (But it wasn't clear to me 'til
now.)

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 10/28/21 11:50 AM, 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?
>>
>> (*) Note to self
>>
>> When I tried changing that array, the compiler did not let me to ---
>> with either declaration. (So it appears there is no *effective*
>> difference.)
>>
>> %cat msg.c
>> #include <stdio.h>
>>
>> int main(void) {
>>
>> char const msg[9] = "warming:";
>> msg[0]= 'f';
>> printf("%s\n", msg);
>>
>> }
>> %make msg
>> gcc msg.c -o msg
>> msg.c: In function 'main':
>> msg.c:6:9: error: assignment of read-only location 'msg[0]'
>> 6 | msg[0]= 'f';
>> | ^
>> make: *** [<builtin>: msg] Error 1
>> %
>>
>
> "const" is a type qualifier. "char" is a type specifier. Both are
> members of the larger category called "declaration specifiers". If you
> have a string of declaration specifiers, they can occur in any order you
> like, without any change of meaning.

That's a nice description. Thank you. I'm making the following
parallel in my mind:

type qualifier /is like/ an adjective
type specifier /is like/ a noun

(``Let c be /char/ming, but qualify it as unmovable.'')

Thiago Adams <thiago.adams@gmail.com> writes:

[...]

> So my definition is: when we put typedef in a declaration we declare a
> variable that has no storage.

I don't like to say a variable that has no storage. Even the literal
constants written in the body of your programs are loaded in memory and
the place they occupy *is* storage.

Of course, the whole idea that numbers represent themselves (and the
fact that in languages like C we cannot get the address of literal
number) encourages us to think like you do above, but I think that's not
a very good idea.

On 10/28/21 11:07 PM, Meredith Montgomery wrote:
> "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu> writes:
>
>> On Thursday, October 28, 2021 at 12:26:09 PM UTC-4, Bart wrote:
>> ...
>>> 'const' (as well as short, int, long, float, double, even static and
>>> typedef) can occur anywhere, in any combination, in the declaration of a
>>> base type (what goes on the left before the first variable).
>> ...
>>> However when applied to a pointer, then it must go after *.
>>
>> const char * p
>> char * const q;
>> char const * const r;
>>
>> are all permitted. p is a pointer to const char. q is a const pointer
>> to char. r is a const pointer to const char.
>
> So the order does make a difference here. I mean
>
> char const * r1
>
> is not the same
>
> char const * const r2
>
> because r2 cannot point somewhere else but r1 can.
>
> Thank you.

The top-level grammar for such a declaration is

declaration-specifiers init-declarator-list opt ;

"char const" are the declaration specifiers, while the
init-declarator-list consists of a single declarator with no
initializer, which is "* const r2". "r2" is the identifier being
declared, and after any "*" in a declarator there may be additional type
qualifiers that are not part of the initial list of declaration
specifiers. Unlike the order of the declaration specifiers, the order of
the type qualifiers relative to the "*"s is VERY important.

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.

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;

const applies neither to the first long nor the second, but to the
complete type 'long long'. It's in the middle!

This is interesting as there are now three placements for 'const' rather
than two. As well, of course, as any combination of all three:

const int const unsigned const long const long const x;

All you can really advise is:

* Identify the base type: the part before you get to the bit that
marks the end of the base type, any of: variable/function/param name, (,
*, comma or ).

* If there is at least one const anywhere in that base type, then the
whole base type is const.

> This fits well with the usual best tactic
> for parsing most types - start from the right and work left.

Yeah, so the type of 'c' here:

int *a(void), *b[77], (*c)[5][10];

according to your method, is:

array 10 of array 5 of pointer to (skipping a/b modifiers) int

The actual type is:

pointer to array 5 of array 10 of int

Which is pretty much the opposite!

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. If you are writing a compiler and want to be sure it is
as standards-compliant as you can, 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, 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.