what is the difference between the 2 sentences?

[yezi]

Hi, all:

The 1st sendtence:

int main(){
char string[20]={""};
string[20] = {" connected "};
.....
}


The second sentence:
int main(){
char string[20]={""};
string[20]=" connected ";
....
}

Thanks for any comments;

bin YE

 

[Walter Roberson]

The 1st sendtence:

int main(){
char string[20]={""};

You set up an array of 20 char and initialize it with \0 in the first
position.

string[20] = {" connected "};

You then attempt to assign into the 21st char of that array. The
value you attempt to assign is, however, not a valid expression,
because {} in an expression context is a block grouping which does not
have an associated value. Unlike, for example, (a,b,c) in which the
associated value is the value of c (the comma operator).

....
}

The second sentence:
int main(){
char string[20]={""};

You set up an array of 20 char and initialize it with \0 in the first
position.

string[20]=" connected ";

You then attempt to assign into the 21st char of that array. The
value you attempt to assign is, however, a pointer to a character
string.

...
}

You might want to explore the differences (if any) between

char string1[20] = "connected";
char string2[20] = { "connected" };
char string3[] = "connected";
char string4[] = { "connected" };

 

[August Karlstrom]

int main(){
char string[20]={""};
string[20] = {" connected "};
....
}

$ cat test.c
int main()
{
char string[20] = {""};
string[20] = {" connected "};
return 0;
}
$ gcc test.c
test.c: In function ¡®main¡¯:
test.c:4: error: syntax error before ¡®{¡¯ token


August

 

[slebetman]

Hi, all:

The 1st sendtence:

int main(){
char string[20]={""};
string[20] = {" connected "};
....
}


The second sentence:
int main(){
char string[20]={""};
string[20]=" connected ";
...
}

Both "sentences" 1 and 2 are wrong because you attempt to assign a
string to a char. The value of string[0] or string[10] or string[19]
etc.. can only be a char.

Also trying to access string[20] is a memory access violation. This may
or may not crash your program depending on your OS and CPU. An array
that has the size of 20 elements may only have intexes up to 19.
Remember that in C, arrays are zero based. So, the maximum you can get
is string[19].

In addition, "sentence" 1 is wrong because the {brackets} are not valid
C constructs in that particular case.

 

[Christopher Benson-Manica]

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

 

[David Resnick]

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

str... is apparently only reserved for function names.
from n869:

7.26.10 General utilities <stdlib.h>

[#1] Function names that begin with str and a lowercase
letter (possibly followed by any combination of digits,
letters, and underscore) may be added to the declarations in
the <stdlib.h> header.

7.26.11 String handling <string.h>

[#1] Function names that begin with str, mem, or wcs and a
lowercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <string.h> header.

-David

-David

 

[David Resnick]

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

str... is apparently only reserved for function names.
from n869:

7.26.10 General utilities <stdlib.h>

[#1] Function names that begin with str and a lowercase
letter (possibly followed by any combination of digits,
letters, and underscore) may be added to the declarations in
the <stdlib.h> header.

7.26.11 String handling <string.h>

[#1] Function names that begin with str, mem, or wcs and a
lowercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <string.h> header.

-David

I posted the above hastily. But isn't a variable at block scope
called str... OK? Or can the header make its functions macros, in
which
case this wouldn't fly either?

-David

 

[Mike Wahler]

7.26.11 String handling <string.h>

[#1] Function names that begin with str, mem, or wcs and a
lowercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <string.h> header.

-David

I posted the above hastily. But isn't a variable at block scope
called str... OK? Or can the header make its functions macros, in
which
case this wouldn't fly either?

If strings could fly, we wouldn't need kites.

-Mike

 

[Christopher Benson-Manica]

I posted the above hastily. But isn't a variable at block scope
called str... OK? Or can the header make its functions macros, in
which
case this wouldn't fly either?

IANALL, but I believe this paragraph from 7.1.3 applies...

"All identifiers with external linkage in any of the following
subclauses (including the future library directions) are always reserved
for use as identifiers with external linkage."

The wording of the text you posted seems to preclude the reserved str*
names being macros, so I think the paragraph concerning macro names
immediately preceding the above does not apply. So it seems that str*
are acceptable at block scope (as in OP's code) and at file scope, if
I've read this correctly.

 

[Christopher Benson-Manica]

If strings could fly, we wouldn't need kites.

And here I was reading your post anticipating an illuminating response

 

[Jordan Abel]

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

His use of the identifier does not have external linkage, nor is at file
scope, so he should be fine, at least if he hasn't included string.h or
stdlib.h [possibly even if he has, but i don't know in that case]

 

[Randy Howard]

Jordan Abel wrote

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

His use of the identifier does not have external linkage, nor is at file
scope, so he should be fine, at least if he hasn't included string.h or
stdlib.h [possibly even if he has, but i don't know in that case]

Irrelevant. There is nothing to prevent ISO C 200x from using
that identifier, because it is reserved explicitly for such use.
So, a new compiler comes along, and suddenly the above code
stops working. With or without string.h.

 

[Jordan Abel]

Jordan Abel wrote

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

His use of the identifier does not have external linkage, nor is at file
scope, so he should be fine, at least if he hasn't included string.h or
stdlib.h [possibly even if he has, but i don't know in that case]

Irrelevant. There is nothing to prevent ISO C 200x from using
that identifier, because it is reserved explicitly for such use.

It is? I thought it was only reserved for _external_ identifiers -
which automatic variables are not.

 

[Skarmander]

Jordan Abel wrote

int main(){
char string[20]={""};
string[20] = {" connected "};
}

In addition to the more helpful comments you have already received,
"string" is an identifier reserved for use by the implementation, and
you should thus not use it. (IIRC, that statement only applies if
you've included <string.h>.)

His use of the identifier does not have external linkage, nor is at file
scope, so he should be fine, at least if he hasn't included string.h or
stdlib.h [possibly even if he has, but i don't know in that case]

Irrelevant. There is nothing to prevent ISO C 200x from using
that identifier, because it is reserved explicitly for such use.
So, a new compiler comes along, and suddenly the above code
stops working. With or without string.h.

You're wrong in the sense that C99 does not say that (a hypothetical
future C standard might, but then again that might do anything). Here is
everything relevant to that:

7.1.3:
"Each macro name in any of the following subclauses (including the
future library directions) is reserved for use as specified if any of
its associated headers is included; unless explicitly stated otherwise."

"All identifiers with external linkage in any of the following
subclauses (including the future library directions) are always reserved
for use as identifiers with external linkage."

"Each identifier with file scope listed in any of the following
subclauses (including the future library directions) is reserved for use
as a macro name and as an identifier with file scope in the same name
space if any of its associated headers is included."

7.1.4: "Any function declared in a header may be additionally
implemented as a function-like macro defined in the header [...]"

7.26.10: "Function names that begin with str and a lowercase letter may
be added to the declarations in the <stdlib.h> header."

7.26.11: "Function names that begin with str, mem, or wcs and a
lowercase letter may be added to the declarations in the <string.h> header."

Therefore, an identifier mentioned in a "future directions" clause is
reserved only if the associated header is included or if used with
external linkage or both.

A program is free to call anything "string" if it does not give the
identifier external linkage and if it does not include <string.h> or
<stdlib.h>. Whether that is *wise* is another matter, since it's easy to
break things by adding a header.

S.

 

[Randy Howard]

Skarmander wrote

A program is free to call anything "string" if it does not give the
identifier external linkage and if it does not include <string.h> or
<stdlib.h>. Whether that is *wise* is another matter, since it's easy to
break things by adding a header.

You are correct. My bad. Of course, one wonders why
constructing a program that might not be able to include either
header would be worth the use of such an identifier.

 

[Skarmander]

Skarmander wrote



You are correct. My bad. Of course, one wonders why
constructing a program that might not be able to include either
header would be worth the use of such an identifier.

The restriction that no identifier beginning with "str" and a lowercase
letter can be used after including <stdlib.h> is rather easy to violate
unwittingly, and that any such program strictly speaking invokes
undefined behavior would take many by surprise, I'd wager.

No declaring functions named "strict_check" or "strong_typing" or
"strength_reduce" in your compiler. No declaring
"strawberry_fields_forever" or "strangers_in_the_night" either, but I'd
imagine that's less of a problem.

In practice the undefined behavior caused by this would only have
dramatic consequences on the DeathStation 9000, but of course it would
be impossible for the standard to make it more specific ("yes, we
suppose strength_reduce might be OK... no, strdup would not be...")

S.

 

[Randy Howard]

Skarmander wrote

The restriction that no identifier beginning with "str" and a lowercase
letter can be used after including <stdlib.h> is rather easy to violate
unwittingly, and that any such program strictly speaking invokes
undefined behavior would take many by surprise, I'd wager.

All true. However, if you /know/ of the restriction, and still
choose to violate it, I wonder why. I expect people to do it
without knowing, just as the void main crowd will never
disappear. It is amongst those that /do know/ that the question
arises.

 

[Skarmander]

Skarmander wrote



All true. However, if you /know/ of the restriction, and still
choose to violate it, I wonder why. I expect people to do it
without knowing, just as the void main crowd will never
disappear. It is amongst those that /do know/ that the question
arises.

#include <stdlib.h>
#include <stdio.h>

void strike_me_down_oh_DeathStation_9000() {
puts(
"That you can read this message doesn't mean something "
"awful won't happen soon."
);
}

int main(void) {
strike_me_down_oh_DeathStation_9000();
return 0;
}

It's only undefined behavior, but I like it.

S.

 

[Mike Wahler]

And here I was reading your post anticipating an illuminating response

puts("Everyone's gotta have a bit of fun now and then. ";

-Mike

 

[Mark McIntyre]

puts("Everyone's gotta have a bit of fun now and then. ";

syntax error: missing )