Crazy stuff

[Chumbo]

If I have this(please bear with me - this is a case of a former java
guy going back to C ;-)

int main () {
char *tokconvert(cha r*);
char str[] = "dot.delimited. str";
char *result;

result = tokconvert(str) ;
return 0;
}

char *tokconvert(cha r *strToConvert) {

char *token;
char *tokDelim =",.";

token=strtok(st rToConvert, tokDelim);

while(token != NULL) {
printf("Token -> %s \n", token);
token=strtok(NU LL, tokDelim);
}
}

the thing compiles and runs fine, however if I declare char *str =
"dot.delimited. str" (instead of char str[] = "dot.delimited. str") the
whole thing falls on its ass real bad (bus error) - strtok is defined
as char *strtok(char *, const char *) - what's going on?

more craziness: if I declare/initialise

char *str;
str = strdup("dot.del imited.str)

inside tokconvert (instead of main) and pass that to strtok - it runs
fine!!

any thoughts are most welcome..

chumbo.

P.S.
btw this is on FreeBSD 5.1.2 (using gcc 3.3.3)

[Gordon Burditt]

>> strtok()s first argument is a char *, and is overwritten to produce the

token (yes, this is a terrible way of doing things, as an ex-Java man you
probably expect something like the Java string tokeniser).

So far, so good.

char *str = "My string"; creates a constant string in read-only memory.

The line above is completely wrong. "My string" is a string literal,
and the C standard states that it has the type array of char.
Specifically NOT array of const char. So it is not a constant string.
Furthermore, C does not define any such thing as "read-only memory".

C *DOES* define certain memory areas, such as string literals, which
cannot be written on without invoking undefined behavior. This
is something the implementation is free to put in "read-only memory".
(Or it might not, on implementations with no memory protection.)

char str[] = "My string"; creates a string in read-write memory.

The line above creates an array of chars that may be modified,
provided that its bounds are not exceeded. C does not define any such
thing as "read-write memory".

C *DOES* define certain memory areas, such as non-const variables,
that can be written on without invoking undefined behavior.
It is reasonable to conclude that the implementation must put
this in memory that can be read and written, hence "read-write memory".

C does not define a (human) name, address, social security number,
or quantity of currency, but it is still possible to talk about
programs that handle data described like this.

Gordon L. Burditt

[Endymion Ponsonby-Withermoor III]

"Chumbo" <ch*********@ho tmail.com> wrote in message

the thing compiles and runs fine, however if I declare char *str =
"dot.delimited. str" (instead of char str[] = "dot.delimited. str") the
whole thing falls on its ass real bad (bus error) - strtok is defined
as char *strtok(char *, const char *) - what's going on?

This is because doing the declaration as
char *str = "dot.delimited. str";
embeds a CONSTANT string somewhere, and then sets the pointer to
point to it. You can not WRITE to constant strings. (Well, you shouldn't
and shouldn't be able to, but some old C implementations allowed this).

Doing it as
char str[]="dot.delimited .str";
creates a character array on the stack, of exactly the right
length, and initialises it with the given string (by something
similar to strcpy()). There are thus TWO copies of "dot.delimited. str":
one in the CONSTANT STRING space, and a second in the data space. You
can freely write the latter, but not the former.

Pointers and arrays are not interchangeable .

Richard [in PE12]

[Flash Gordon]

On Mon, 8 Nov 2004 19:47:25 -0000
"Endymion Ponsonby-Withermoor III"
<m_a_r_v_i_n@pa ra----and----.want-to-do.coe.ukk> wrote:

"Chumbo" <ch*********@ho tmail.com> wrote in message

the thing compiles and runs fine, however if I declare char *str =
"dot.delimited. str" (instead of char str[] = "dot.delimited. str")
the whole thing falls on its ass real bad (bus error) - strtok is
defined as char *strtok(char *, const char *) - what's going on?
This is because doing the declaration as
char *str = "dot.delimited. str";
embeds a CONSTANT string somewhere, and then sets the pointer to
point to it. You can not WRITE to constant strings. (Well, you
shouldn't and shouldn't be able to, but some old C implementations
allowed this).

The C standard says it is not const. The reason you should not write to
it is that the C standard says that writing to a string literal invokes
undefined behaviour. This meens that the compiler is allowed to let you
write to it, and one common effect of doing this would be to also change
the string literal "blah blah dot.delimited.s tr"
Doing it as
char str[]="dot.delimited .str";
creates a character array on the stack,
1) C does not require a stack.
2) that line could be placed outside of any function definitions in
which case the string is unlikely to be stored on the stack if the
machine has a stack.
of exactly the right
length, and initialises it with the given string
True.
(by something
similar to strcpy()). There are thus TWO copies of
"dot.delimited. str": one in the CONSTANT STRING space, and a second in
the data space. You can freely write the latter, but not the former.
Possibly true of it is an automatic array, definitely not always strue
if it is not an automatic array.

All you know is that the object gets initialised, this could be done
with code equivalent to
str[0]='d';
str[1]='o';
...

For a non-automatic other options are available.
Pointers and arrays are not interchangeable .

True.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Old Wolf]

Barry Schwarz <sc******@deloz .net> wrote:

(Chumbo) wrote:

char *tokconvert(cha r *strToConvert) {

char *token;
char *tokDelim =",.";
token=strtok(st rToConvert, tokDelim);

while(token != NULL) {
printf("Token -> %s \n", token);
token=strtok(NU LL, tokDelim);
}
}

How can this function compile fine? It is required to return a
pointer to char yet there is no return statement in the function at
all.

It must compile fine. There is only undefined behaviour if
control actually reaches the end of the function at runtime.

[Jack Klein]

On 8 Nov 2004 06:57:17 GMT, go***********@b urditt.org (Gordon Burditt)
wrote in comp.lang.c:

strtok()s first argument is a char *, and is overwritten to produce the
token (yes, this is a terrible way of doing things, as an ex-Java man you
probably expect something like the Java string tokeniser).
So far, so good.

char *str = "My string"; creates a constant string in read-only memory.

The line above is completely wrong. "My string" is a string literal,
and the C standard states that it has the type array of char.
Specifically NOT array of const char. So it is not a constant string.
Furthermore, C does not define any such thing as "read-only memory".

C *DOES* define certain memory areas, such as string literals, which
cannot be written on without invoking undefined behavior. This
is something the implementation is free to put in "read-only memory".
(Or it might not, on implementations with no memory protection.)

C does not define "memory areas" at all. Modifying a string literal,
or modifying any object defined with the const qualifier, is undefined
behavior. There is not even a requirement that such an operation
fails, merely that the behavior is undefined if the attempt is made.

char str[] = "My string"; creates a string in read-write memory.

The line above creates an array of chars that may be modified,
provided that its bounds are not exceeded. C does not define any such
thing as "read-write memory".

C *DOES* define certain memory areas, such as non-const variables,
that can be written on without invoking undefined behavior.
It is reasonable to conclude that the implementation must put
this in memory that can be read and written, hence "read-write memory".

C still does not define "memory areas" at all. It defines objects
that may be freely modified by a program. Almost all of them, in
fact, other than those defined const and string literals. Nowhere
does the standard mention that these must be stored in a special
"memory area". It also doesn't specify whether any particular
modifiable object is in SRAM, DRAM, or virtual memory that might be
swapped out to a page file at any particular time.
C does not define a (human) name, address, social security number,
or quantity of currency, but it is still possible to talk about
programs that handle data described like this.
It is indeed quite possible for a C program to use data objects as
representations of "real world" concepts.

But it is indeed quite impossible to force a C implementation to
provide "read-only memory" just because you define a string literal.
Gordon L. Burditt
The poster to whom I replied wrote a sentence that contained two very
specific factual errors, directly in contradiction to the C language
standard:
char *str = "My string"; creates a constant string in read-only memory.

The two errors are:

1. The type of "My string" in the snippet is 'array of char', most
specifically not 'array of constant char'. See 6.4.5 P5.

2. The standard states that an implementation may (note MAY) place
certain const objects and string literals in "a read-only region of
storage" (footnote 112). Note that footnotes are not normative, and
the term "read-only" is not specifically defined in the standard.
Most certainly, there is no requirement or guarantee that "My string"
in the snippet above will be placed in any sort of specially qualified
memory.

If you think either of my corrections is inaccurate, kindly quote
chapter and verse from the standard to contradict them.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.l earn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Endymion Ponsonby-Withermoor III]

"Flash Gordon" <sp**@flash-gordon.me.uk> wrote in message
news:vk******** ****@brenda.fla sh-

The C standard says it is not const. The reason you should not write to
it is that the C standard says that writing to a string literal invokes
undefined behaviour.
OK. I sit corrected.
write to it, and one common effect of doing this would be to also change
the string literal "blah blah dot.delimited.s tr"

Yes. That is because "dot.delimited. str" can be duplicate-merged with any
quoted-string that ends with it.
Richard [in PE12]

[Malcolm]

"Jack Klein" <ja*******@spam cop.net> wrote

Furthermore, C does not define any such thing as "read-only memory".
C does not define any such thing as "read-write memory".

That is true, but does not apply here. The result of attempting to
modify a string literal is undefined behavior. This is true not
because the type of the string literal is array of const char, but
because the C standard specifically states that it is so.

So C defines various terms, but how does it define them? In the Standard,
which is an English-language document. So sometimes C will also define the
words used to define these terms.
See the problem?
Ultimately we have to use terms like "read-only memory", which are not
defined by the C standard, but which have meanings given to them by usage.

If the OP doesn't understand why an attempt to modify a string literal
causes a crash, then its unlikely that he will be familiar with the term
"string literal". He may also be shaky on "undefined behaviour". So a
technically more accurate explanation is in fact more confusing.

[Barry Schwarz]

On 8 Nov 2004 16:13:46 -0800, ol*****@inspire .net.nz (Old Wolf) wrote:

Barry Schwarz <sc******@deloz .net> wrote:

(Chumbo) wrote:

>char *tokconvert(cha r *strToConvert) {
>
> char *token;
> char *tokDelim =",.";
> token=strtok(st rToConvert, tokDelim);
>
> while(token != NULL) {
> printf("Token -> %s \n", token);
> token=strtok(NU LL, tokDelim);
> }
>}

How can this function compile fine? It is required to return a
pointer to char yet there is no return statement in the function at
all.

It must compile fine. There is only undefined behaviour if
control actually reaches the end of the function at runtime.

I couldn't find in the standard where the missing return requires a
diagnostic. All the compilers I have used did provide one so I guess
I've been spoiled.
<<Remove the del for email>>

[Lawrence Kirby]

On Wed, 10 Nov 2004 18:55:27 -0800, Barry Schwarz wrote:

On 8 Nov 2004 16:13:46 -0800, ol*****@inspire .net.nz (Old Wolf) wrote:
....

It must compile fine. There is only undefined behaviour if
control actually reaches the end of the function at runtime.

I couldn't find in the standard where the missing return requires a
diagnostic. All the compilers I have used did provide one so I guess
I've been spoiled.

It doesn't. I guess this goes back to the days when C didn't have a void
type.

Also just reaching the end of the function doesn't invoke undefined
behaviour, in the words of C99 6.9.1:

"If the } that terminate a function is reached, and the value of the
function call is used by the caller, the behavior is undefined."

In C90 you can also use return; i.e. with no expression in a function with
a non-void return type. C99 makes this a constraint violation but still
allows falling off the end of the function.

[Dave Thompson]

On Sun, 7 Nov 2004 05:58:35 +0000 (UTC), dj******@csclub .uwaterloo.ca
(Dave Vandervies) wrote:

In article <50************ **************@ posting.google. com>,
Chumbo <ch*********@ho tmail.com> wrote:

<snip: modification, namely strtok'enizing, of string literal value vs
array initialized to contain string>

FAQ 1.32, 16.6 at the usual places and
http://www.eskimo.com/~scs/C-faq/top.html

char str[] = "dot.delimited. str";

This allocates an array of char and populates it with the characters
in the string "dot.delimited. str" (including the terminating '\0').
The array is in the automatic-allocation space (we can call this "the
stack", but we prefer not to, because the function-invocation stack that
it exists in is not the same stack as the "processor' s stack segment"
stack (which need not even exist) that people typically assume we're
talking about), and therefore that we can do pretty much whatever we

Huh? Unless I completely misunderstand what you are saying:
while the C standard does not specify implementation techniques, and
so can't topically rely on "the stack", on every machine I know of
that has a "processor stack segment", or indeed just a "processor
(memory) stack" anywhere, it was designed to be and in fact is used
for C (and other HLL) function-invocation frames in a stack fashion.

<snip rest>

- David.Thompson1 at worldnet.att.ne t