Differences between 'const char' and 'char'

[hokieghal99]

What is the difference between these two statements? Are there any major
differences?

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Thanks!!!

[Mark A. Odell]

hokieghal99 <ho********@hotmail.com> wrote in
news:bl*********@solaris.cc.vt.edu:

What is the difference between these two statements? Are there any major
differences?

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Only a compile time difference. If you attempt to write to the first
definition of filename, as in filename[0] = 'I' you will get a
compile-time error. Do the same thing for the second definition and you
will get no error and filename[] will contain "Ips_c.txt".

off-topic: some implementations may place the const version into some sort
of read-only memory.

--
- Mark ->
--

[Ben Pfaff]

hokieghal99 <ho********@hotmail.com> writes:

What is the difference between these two statements? Are there any
major differences?

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

First, these are declarations, not statements[*]. Second, yes,
there is a difference: attempting to modify the former `filename'
yields undefined behavior. The C implementation is allowed to
place the former `filename' in a "read-only" section of memory.
[*] In C99, a declaration can be a statement, but it's still
misleading.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[Ben Pfaff]

"Mark A. Odell" <no****@embeddedfw.com> writes:

hokieghal99 <ho********@hotmail.com> wrote in
news:bl*********@solaris.cc.vt.edu:

What is the difference between these two statements? Are there any major
differences?

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";
Only a compile time difference. If you attempt to write to the first
definition of filename, as in filename[0] = 'I' you will get a
compile-time error. Do the same thing for the second definition and you
will get no error and filename[] will contain "Ips_c.txt".

It may be only a compile-time difference with your C
implementation, but the standard doesn't say anything about that.
off-topic: some implementations may place the const version into some sort
of read-only memory.

Thus, there may be a runtime difference.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro

[Mark A. Odell]

Ben Pfaff <bl*@cs.stanford.edu> wrote in
news:87************@pfaff.stanford.edu:

Only a compile time difference. If you attempt to write to the first
definition of filename, as in filename[0] = 'I' you will get a
compile-time error. Do the same thing for the second definition and you
will get no error and filename[] will contain "Ips_c.txt".

It may be only a compile-time difference with your C
implementation, but the standard doesn't say anything about that.

So the compiler doesn't need to issue an error?

off-topic: some implementations may place the const version into some
sort of read-only memory.

Thus, there may be a runtime difference.

If the module had an error and didn't compile I wouldn't expect a run-time
at all. What am I missing?

--
- Mark ->
--

[Ben Pfaff]

"Mark A. Odell" <no****@embeddedfw.com> writes:

Ben Pfaff <bl*@cs.stanford.edu> wrote in
news:87************@pfaff.stanford.edu:

Only a compile time difference. If you attempt to write to the first
definition of filename, as in filename[0] = 'I' you will get a
compile-time error. Do the same thing for the second definition and you
will get no error and filename[] will contain "Ips_c.txt".

It may be only a compile-time difference with your C
implementation, but the standard doesn't say anything about that.

So the compiler doesn't need to issue an error?

Some such errors cannot be detected at compile time, and many
such errors are not required to be detected at compile time. In
the particular case you describe, yes, a diagnostic is required.

off-topic: some implementations may place the const version into some
sort of read-only memory.

Thus, there may be a runtime difference.

If the module had an error and didn't compile I wouldn't expect a run-time
at all. What am I missing?

That not every attempted modification of a const-qualified object
can be detected at compile time.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro

[Micah Cowan]

Ben Pfaff <bl*@cs.stanford.edu> writes:

[*] In C99, a declaration can be a statement, but it's still
misleading.

Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

-Micah

[E. Robert Tisdale]

Ben Pfaff wrote:

First, these are declarations, not statements.

You are probably confusing statements with imperatives.

[Ben Pfaff]

Micah Cowan <mi***@cowan.name> writes:

Ben Pfaff <bl*@cs.stanford.edu> writes:

[*] In C99, a declaration can be a statement, but it's still
misleading.

Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

Ah, now that I check the standard, instead of just trying to
recall it, I see that you're right. In particular, I had thought
that a declaration was now one kind of statement, whereas in fact
a block now can contain any mix of declarations and statements.
The two are similar in terms of what parses[*] but, indeed, a
declaration is never a statement.
[*] If a declaration were a statement, then `if(a) int b;' would
parse, but since it isn't, it doesn't. That (and similar) are
the one difference that I see between the two possibilities.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x1f6},*p=
b,x,i=24;for(;p+=!*p;*p/=4)switch(x=*p&3)case 0:{return 0;for(p--;i--;i--)case
2:{i++;if(1)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Ben Pfaff]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Ben Pfaff wrote:

First, these are declarations, not statements.

You are probably confusing statements with imperatives.

Could you just go away please? C does not have a concept of
"imperatives", and you damn well know it.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[E. Robert Tisdale]

Ben Pfaff wrote:

C does not have a concept of "imperatives".

It certainly does.

statements:

1. declaration statement and
2. executable statement.

Statements are *terminated* with a semicolon ;

[Ben Pfaff]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Ben Pfaff wrote:

C does not have a concept of "imperatives".

It certainly does.

statements:

1. declaration statement and
2. executable statement.

Statements are *terminated* with a semicolon ;

The word "imperative" does not appear in the C standard.
--
"This is a wonderful answer.
It's off-topic, it's incorrect, and it doesn't answer the question."
--Richard Heathfield

[Noah Roberts]

Micah Cowan wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

[*] In C99, a declaration can be a statement, but it's still
misleading.

Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

Since I am unfamiliar with C99 (only ansi) I take the above to mean that
you don't have to declair all of your variables at the beginning of a
block any longer? Is the following also legal then?

for (int i = 0; i < x; i++) ....;

NR

[hokiegal99]

E. Robert Tisdale wrote:

Statements are *terminated* with a semicolon ;

This is what I've been taught. That's why I said that these
are statements:

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Maybe we're being too anal about this. Maybe we all need to get a life.

[j]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F**************@jpl.nasa.gov...

Ben Pfaff wrote:

C does not have a concept of "imperatives".

It certainly does.

statements:

1. declaration statement and
2. executable statement.

Statements are *terminated* with a semicolon ;

6.8 Statements and blocks
Syntax
1 statement:
labeled-statement
compound-statement
expression-statement
selection-statement
iteration-statement
jump-statement

I don't see in the above anything referring to a declarator as a statement.
Furthermore, after reading section 6.8 of c99(which I doubt there is much
difference
between what is stated in c99 in this regard and c89/90), claiming that
anything which
ends in a semi-colon qualifies as a statement, doesn't seem to be entirely
correct.

[Ben Pfaff]

Noah Roberts <nr******@dontemailme.com> writes:

Micah Cowan wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

[*] In C99, a declaration can be a statement, but it's still
misleading. Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

Since I am unfamiliar with C99 (only ansi)

C99 *is* an ANSI standard.
I take the above to mean that you don't have to declair all of
your variables at the beginning of a block any longer?
Yes.
Is the following also legal then?

for (int i = 0; i < x; i++) ....;

Yes, but as a separate change. The first clause of a `for'
statement isn't part of a block.
--
"I've been on the wagon now for more than a decade. Not a single goto
in all that time. I just don't need them any more. I don't even use
break or continue now, except on social occasions of course. And I
don't get carried away." --Richard Heathfield

[Ben Pfaff]

hokiegal99 <ho********@hotmail.com> writes:

E. Robert Tisdale wrote:

Statements are *terminated* with a semicolon ;
This is what I've been taught. That's why I said that these
are statements:

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Just because something is terminated with a semicolon does not
make it a statement. Declarations can also be terminated by a
semicolon, as in this case.
Maybe we're being too anal about this. Maybe we all need to get a life.

Precision is important.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Micah Cowan]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Micah Cowan <mi***@cowan.name> writes:

Ben Pfaff <bl*@cs.stanford.edu> writes:

[*] In C99, a declaration can be a statement, but it's still
misleading.
Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

Ah, now that I check the standard, instead of just trying to
recall it, I see that you're right. In particular, I had thought
that a declaration was now one kind of statement, whereas in fact
a block now can contain any mix of declarations and statements.
The two are similar in terms of what parses[*] but, indeed, a
declaration is never a statement.

In C++, it's a statement, which might have been better in some sense
[*] If a declaration were a statement, then `if(a) int b;' would
parse, but since it isn't, it doesn't. That (and similar) are
the one difference that I see between the two possibilities.

The only case where the difference has actually affected me is
the infortunate fact that labeled statements doesn't include
labeled declarations (which is an impossibility in C). This is
particularly annoying in switch statements, where the following
(made up):

case evt_menu_event_code:
unsigned char low_octet, hi_octet;

low_octet = e->event_data & 0xff;
hi_octet = (e->event_data >> 8) & 0xff;

handle_menu(low_octet, hi_octet);
break;

Seems reasonable, but is still illegal (requiring a surrounding {
and } to legalize it).

-Micah

[Micah Cowan]

Ben Pfaff <bl*@cs.stanford.edu> writes:

Noah Roberts <nr******@dontemailme.com> writes:

Micah Cowan wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

>[*] In C99, a declaration can be a statement, but it's still
>misleading.
Still can't be: only in C++. In C99, they're simply allowed to be
intermixed with statements, but they're still syntactically
distinct.

Since I am unfamiliar with C99 (only ansi)

C99 *is* an ANSI standard.

I take the above to mean that you don't have to declair all of
your variables at the beginning of a block any longer?

Yes.

Is the following also legal then?

for (int i = 0; i < x; i++) ....;

Yes, but as a separate change. The first clause of a `for'
statement isn't part of a block.

At this point, it's worth pointing out that certain *other*
similar changes were *not* made; for example:

while (int c = getchar())
...

Is still illegal in C.

-Micah

[E. Robert Tisdale]

Ben Pfaff wrote:

hokiegal99 writes:

E. Robert Tisdale wrote:

Statements are *terminated* with a semicolon ;

This is what I've been taught. That's why I said that these
are statements:

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Just because something is terminated with a semicolon does not
make it a statement. Declarations can also be terminated by a
semicolon, as in this case.

Maybe we're being too anal about this. Maybe we all need to get a life.

Precision is important.

Yes, but the ANSI/ISO standards documents are *not* Holy Scripture --
they are not even a dictionary of the English language.

Your attitude reminds me of an olde tyme preacher
with no formal seminary training
or any education beyond that required to read "The Bible"
but who is "filled with the spirit"
and interprets scripture just a little too literally.

Please just back away from your copy
of the ANSI/ISO C standards documents a little.

A declaration is a statement.
An executable statement is an imperative.
Your attempt to narrow these definitions is anal.
It doesn't contribute anything except confusion.

[Richard Heathfield]

hokiegal99 wrote:

E. Robert Tisdale wrote:

Statements are *terminated* with a semicolon ;
This is what I've been taught.

You were taught incorrectly.
That's why I said that these
are statements:

const char filename[] = "ips_c.txt";
char filename[] = "ips_c.txt";

Maybe we're being too anal about this. Maybe we all need to get a life.

You don't need a life. You need a grammar. There's one in K&R2.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Ben Pfaff]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Please just back away from your copy
of the ANSI/ISO C standards documents a little.

A declaration is a statement.

Nope.
--
"Am I missing something?"
--Dan Pop

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Ben Pfaff wrote:

Precision is important.
Yes, but the ANSI/ISO standards documents are *not* Holy Scripture --
they are not even a dictionary of the English language.

The Highway Code is not holy scripture, either, but you'd better keep to
it when on the road.
Your attitude reminds me of an olde tyme preacher

And your attitude reminds me of those guys who claim they can drive at
murderous speeds "because the road is clearly suited to it".

Richard

[Chris Dollin]

E. Robert Tisdale wrote:

A declaration is a statement.
An executable statement is an imperative.
C doesn't define that term: it's part of the informal meta-language,
not part of C. You are, sadly, wrong. What's more, in C, declarations
are also imperative - so that term doesn't distinguish a declaration
from a statement. Furthermore, there are C statements that are not
imperative (and not declarations).
Your attempt to narrow these definitions is anal.
No - it's a natural consequence of working in a specific domain.
It doesn't contribute anything except confusion.

I don't think anyone else but you was confused about this.

--
Chris "int ch = getchar(); 1 + 2;" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Richard Heathfield]

Ben Pfaff wrote:

Noah Roberts <nr******@dontemailme.com> writes:

Since I am unfamiliar with C99 (only ansi)

C99 *is* an ANSI standard.

Just for the sake of completeness:

In 1999, ISO ratified ISO/IEC 9899:1999 as a replacement for ISO/IEC
9899:1990. It was not until 2000 that ANSI adopted this standard, so I
suppose we ought really to say that C99 is an ISO standard, and C2000 (or,
for those who have already forgotten Y2K, perhaps C00) is perhaps a more
accurate name for the new ANSI standard. (They are, however, effectively
the same standard, so IMHO Ben was quite within his rights to say that C99
is an ANSI standard. I am expanding his statement, rather than correcting
it.)

Implementors' uptake for this new standard has been slow. For maximum
portability, C programmers would be well advised to work within the common
subset of C90 and C99 as far as possible.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[j]

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bl**********@sparta.btinternet.com...

Ben Pfaff wrote:

Noah Roberts <nr******@dontemailme.com> writes:

Since I am unfamiliar with C99 (only ansi)
C99 *is* an ANSI standard.

Just for the sake of completeness:

In 1999, ISO ratified ISO/IEC 9899:1999 as a replacement for ISO/IEC
9899:1990. It was not until 2000 that ANSI adopted this standard, so I
suppose we ought really to say that C99 is an ISO standard, and C2000 (or,
for those who have already forgotten Y2K, perhaps C00) is perhaps a more
accurate name for the new ANSI standard. (They are, however, effectively
the same standard, so IMHO Ben was quite within his rights to say that C99
is an ANSI standard. I am expanding his statement, rather than correcting
it.)

It is noted on the ANSI webstore that c99 is formerly known
as ISO/IEC/ANSI 9899:1999 and is now known as
ISO/IEC/INCITS 9899:1999

So referring to it as ANSI is not entirely correct
Even though INCITS operates under ANSI
it would be more correct to refer to the actual groups
that are responsible for the standard.
Which is: ISO/IEC/INCITS
Implementors' uptake for this new standard has been slow. For maximum
portability, C programmers would be well advised to work within the common
subset of C90 and C99 as far as possible.
--
Richard Heathfield : bi****@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

[Jeremy Yallop]

[crosspost added]

Micah Cowan wrote:

Ben Pfaff <bl*@cs.stanford.edu> writes:

Noah Roberts <nr******@dontemailme.com> writes:

> Is the following also legal then?
>
> for (int i = 0; i < x; i++) ....;

Yes, but as a separate change. The first clause of a `for'
statement isn't part of a block.

At this point, it's worth pointing out that certain *other*
similar changes were *not* made; for example:

while (int c = getchar())
...

Is still illegal in C.

It's valid C++, though (as is "if (int c = getchar())" etc.). Were
these additional changes considered and rejected by the committee, or
simply not considered at all? I suspect that the "for" version was a
common extension before C99 and the others were not. (Admittedly,
they appear to be more useful in C++, where they can be used in
conjunction with conversion operators to bool (etc.) and to support
the RAII idiom).

Jeremy.

[Clive D. W. Feather]

In article <bl************@ID-114079.news.uni-berlin.de>, Jeremy Yallop
<je****@jdyallop.freeserve.co.uk> writes

> for (int i = 0; i < x; i++) ....;

[is legal] while (int c = getchar())
...
Is still illegal in C.

Were
these additional changes considered and rejected by the committee, or
simply not considered at all?

They were considered and rejected, basically because it was felt there
was insufficient utility.

--
Clive D.W. Feather, writing for himself | Home: <cl***@davros.org>
Tel: [phone] (work) | Web: <http://www.davros.org>
Fax: [phone] | Work: <cl***@demon.net>
Written on my laptop; please observe the Reply-To address