By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,595 Members | 3,721 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,595 IT Pros & Developers. It's quick & easy.

what is the difference between the 2 sentences?

P: n/a
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

Nov 23 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
In article <11**********************@o13g2000cwo.googlegroups .com>,
yezi <ye*****@hotmail.com> wrote:
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" };
--
"It is important to remember that when it comes to law, computers
never make copies, only human beings make copies. Computers are given
commands, not permission. Only people can be given permission."
-- Brad Templeton
Nov 23 '05 #2

P: n/a
yezi wrote:
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

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
General Public License.
Nov 23 '05 #3

P: n/a
yezi wrote:
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.

Nov 23 '05 #4

P: n/a
yezi <ye*****@hotmail.com> 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>.)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 23 '05 #5

P: n/a

Christopher Benson-Manica wrote:
yezi <ye*****@hotmail.com> 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>.)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.


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

Nov 23 '05 #6

P: n/a

David Resnick wrote:
Christopher Benson-Manica wrote:
yezi <ye*****@hotmail.com> 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>.)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.


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

Nov 23 '05 #7

P: n/a
"David Resnick" <ln********@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
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
Nov 23 '05 #8

P: n/a
David Resnick <ln********@gmail.com> wrote:
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 | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 23 '05 #9

P: n/a
Mike Wahler <mk******@mkwahler.net> wrote:
If strings could fly, we wouldn't need kites.


And here I was reading your post anticipating an illuminating response
:-)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 23 '05 #10

P: n/a
On 2005-11-23, Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
yezi <ye*****@hotmail.com> 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]
Nov 23 '05 #11

P: n/a
Jordan Abel wrote
(in article <sl*******************@random.yi.org>):
On 2005-11-23, Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
yezi <ye*****@hotmail.com> 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.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Nov 23 '05 #12

P: n/a
On 2005-11-23, Randy Howard <ra*********@FOOverizonBAR.net> wrote:
Jordan Abel wrote
(in article <sl*******************@random.yi.org>):
On 2005-11-23, Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
yezi <ye*****@hotmail.com> 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.
Nov 23 '05 #13

P: n/a
Randy Howard wrote:
Jordan Abel wrote
(in article <sl*******************@random.yi.org>):

On 2005-11-23, Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
yezi <ye*****@hotmail.com> 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.
Nov 23 '05 #14

P: n/a
Skarmander wrote
(in article <43***********************@news.xs4all.nl>):
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.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Nov 23 '05 #15

P: n/a
Randy Howard wrote:
Skarmander wrote
(in article <43***********************@news.xs4all.nl>):

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.

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.
Nov 23 '05 #16

P: n/a
Skarmander wrote
(in article <43***********************@news.xs4all.nl>):
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.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Nov 23 '05 #17

P: n/a
Randy Howard wrote:
Skarmander wrote
(in article <43***********************@news.xs4all.nl>):

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.

#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.
Nov 23 '05 #18

P: n/a

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:dm**********@chessie.cirr.com...
Mike Wahler <mk******@mkwahler.net> wrote:
If strings could fly, we wouldn't need kites.


And here I was reading your post anticipating an illuminating response
:-)


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

-Mike
Nov 23 '05 #19

P: n/a
On Wed, 23 Nov 2005 23:05:23 GMT, in comp.lang.c , "Mike Wahler"
<mk******@mkwahler.net> wrote:
puts("Everyone's gotta have a bit of fun now and then. :-)";


syntax error: missing )
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 24 '05 #20

P: n/a
Randy Howard wrote:
Jordan Abel wrote
(in article <sl*******************@random.yi.org>):

On 2005-11-23, Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:
yezi <ye*****@hotmail.com> 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.


It is difficult to choose identifiers that no future
C Committee will proclaim off-limits. Did you, by any
chance, use `restrict' as an identifier? If so, what do
you think of C90's guarantee that `restrict' was in the
name space reserved for your use?

--
Er*********@sun.com
Nov 24 '05 #21

P: n/a
Eric Sosman wrote
(in article <T-********************@comcast.com>):
It is difficult to choose identifiers that no future
C Committee will proclaim off-limits.
True.
Did you, by any chance, use `restrict' as an identifier?
No, I never did. Pure luck I suppose.
If so, what do
you think of C90's guarantee that `restrict' was in the
name space reserved for your use?


*shrug* Better than using strrestrict I suppose. :-)

Seriously, I don't use it now that it does exist, and probably
never will. I've yet to encounter a situation in which it was
needed, for that matter, I can say the same thing about
everything in C99.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

Nov 24 '05 #22

P: n/a

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:0m********************************@4ax.com...
On Wed, 23 Nov 2005 23:05:23 GMT, in comp.lang.c , "Mike Wahler"
<mk******@mkwahler.net> wrote:
puts("Everyone's gotta have a bit of fun now and then. :-)";


syntax error: missing )


Now that *was* fun, wasn't it? :-)

-Mike
Nov 24 '05 #23

P: n/a
On Wed, 23 Nov 2005 20:46:28 -0500, Eric Sosman
<es*****@acm-dot-org.invalid> wrote:
<snip: about reservations of str[a-z]*>
It is difficult to choose identifiers that no future
C Committee will proclaim off-limits. Did you, by any
chance, use `restrict' as an identifier? If so, what do
you think of C90's guarantee that `restrict' was in the
name space reserved for your use?


I did use 'inline'. However, stealing an identifier for a keyword
whose use(s) cannot substitute for an identifier, at least is a
required diagnostic so I am guaranteed to learn of the problem. Taking
an identifier for a library routine, or a macro that must act pretty
much like a routine, has a significant chance of silently failing.

- David.Thompson1 at worldnet.att.net
Dec 5 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.