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)

[Lawrence Kirby]

On Mon, 15 Nov 2004 04:09:47 +0000, Dave Thompson wrote:

....

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.

Well, the 6502 processor, which certainly does have C compilers targetting
it, has a 256 byte processor stack. I suspect the C compilers don't use
that to hold automatic variables.

Lawrence

[Dave Vandervies]

In article <jm************ *************** *****@4ax.com>,
Dave Thompson <da************ *@worldnet.att. net> wrote:

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

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),

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.

This is true, but not what I was saying (or at least not what I intended
to say).

The C (and other HLL) function-invocation stack is an abstract thing on
which continuations[1], automatic variables, and possibly a few things I'm
not thinking of live. The fact that, where they exist, hardware-assisted
stack mechanisms are universally used to (and, in fact, designed to)
implement this doesn't mean they're the same thing; one is a construct
of the language being implemented, and one is the back-end mechanism
used to implement it.

Note that (relevant to the subject, but not to your comments if
I'm understanding them correctly) even on systems without such a
hardware-assisted mechanism (I believe older IBM systems are the
canonical example, though I'd probably get the details wrong if I tried
to remember them) the invocation records (implemented as, say, a linked
list of freestore-allocated invocation frames) need to look, feel, and
smell like a stack - this is an obvious example of a function-invocation
stack not being implemented with a hardware stack.
dave

[1] That is, what to do when the function finishes (including what to
do with the return value, if there is one). Typically this is
implemented as a machine address referring to the point in the calling
code immediately after the actual subroutine call, where the return
value is handled appropriately and the rest of the caller continues
to run.

--
Dave Vandervies dj******@csclub .uwaterloo.ca
Perhaps the original version of the program worked.
OK, this takes us *way* off topic for any computer related newsgroup, but
you've got to admit its a theoretical possibility. --Ken Hagan in comp.arch

[Charlie Gordon]

"Malcolm" <ma*****@55bank .freeserve.co.u k> wrote in message
news:cm******** *@news7.svr.pol .co.uk...

"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.

I agree 100%
Furthermore, strdup() may not be specified in the Standard, it is defined by
POSIX and is widely available on the systems used by beginners. Its semantics
are easy to understand.
On the contrary, strtok() has always been part of the Standard, but is a
constant cause of misunderstandin gs and implementation bugs. IMHO programmers
should be instructed to not use this bastard, not its friends (gets, strncpy,
strncat...)

strtok modifies the string pointed to by its first argument (if not NULL) and
keeps a copy to it in a global variable.
passing it a string literal such as "this is a string" may cause undefined
behaviour, such as crash.
passing it a pointer to automatic storage, such as what you do in the example,
is error prone.
initializing a automatic character array with a string literal is inefficient.
strtok() is flawed is ways beyond the understanding of newbie developpers, it
should not be used.

Chqrlie.

[Charlie Gordon]

"Endymion Ponsonby-Withermoor III"
<m_a_r_v_i_n@pa ra----and----.want-to-do.coe.ukk> wrote in message
news:cm******** **@newsg4.svr.p ol.co.uk...

"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.

you pedants are so picky and righteous !

The C standard did not make it const char to avoid breaking countless sloppy
programs with compile time errors...
And more often than not, inconsistent use of char and string literals, hiding
subtile bugs waiting to bite at runtime.
So it is not "const", but if you try to modify it, you get UB ! Its has the
flavor and behaviour, but not the type...
Gimme a break, I'd rather newbies think it *be* const are understand why they
get a crash.

The case of the missing return statement is even a worse hack to accomodate
historical trash. It is about time some of those remnents from the 70s should
be fixed.

Just exactly what prevented the inclusion of strdup() into the Standard eludes
me !

The case against strtok() is also worth fighting : please stop teaching newbies
to use functions with flawed semantics like this one or its friends : gets(),
strncpy(), strncat()...

Chqrlie.

[Richard Bos]

"Charlie Gordon" <ne**@chqrlie.o rg> wrote:

you pedants are so picky and righteous !
With good reason.
Just exactly what prevented the inclusion of strdup() into the Standard eludes
me !
It's easily emulated and would sit awkwardly in whichever header you put
it in.
The case against strtok() is also worth fighting :
strtok() has its problems, but where it's useful, it's very useful.
please stop teaching newbies to use functions with flawed semantics like
this one or its friends : gets(), strncpy(), strncat()...

Obviously I agree about gets(), and strncpy() is rarely if ever the
right function, but if you won't allow strncat(), which function _do_
you use when you want a length-limited string copy?

Richard

[Charlie Gordon]

Hello,

The case against strtok() is also worth fighting :

strtok() has its problems, but where it's useful, it's very useful.

please stop teaching newbies to use functions with flawed semantics like
this one or its friends : gets(), strncpy(), strncat()...

Obviously I agree about gets(), and strncpy() is rarely if ever the
right function, but if you won't allow strncat(), which function _do_
you use when you want a length-limited string copy?

Why not write one that does what is needed.

Or use a test and write appropriate code for each case.

strncat() is not the worst of these, but it is consistently misused in code I
come across :

strncpy(dest, source, sizeof(dest)); // dangerous !
strncat(dest, source, sizeof(dest)); // worse even!

Chqrlie.

PS: the glove don't fit, you must acquit !

[Lawrence Kirby]

On Tue, 16 Nov 2004 12:36:55 +0100, Charlie Gordon wrote:

....

The case against strtok() is also worth fighting : please stop teaching newbies
to use functions with flawed semantics like this one or its friends : gets(),
strncpy(), strncat()...

What's wrong with strncat()?

Lawrence

[Charlie Gordon]

"Lawrence Kirby" <lk****@netacti ve.co.uk> wrote in message
news:pa******** *************** *****@netactive .co.uk...

On Tue, 16 Nov 2004 12:36:55 +0100, Charlie Gordon wrote:

...

The case against strtok() is also worth fighting : please stop teaching newbies to use functions with flawed semantics like this one or its friends : gets(), strncpy(), strncat()...

What's wrong with strncat()?

It is often misunderstood, and misused :

strncpy(dest, source, sizeof(dest)); // dangerous !
strncat(dest, source, sizeof(dest)); // worse even!

Chqrlie.

[Michael Mair]

Lawrence Kirby wrote:

On Tue, 16 Nov 2004 12:36:55 +0100, Charlie Gordon wrote:

...

The case against strtok() is also worth fighting : please stop teaching newbies
to use functions with flawed semantics like this one or its friends : gets(),
strncpy(), strncat()...

What's wrong with strncat()?

He probably refers to Criminally Stupid Behaviour (TM), such as
ignoring the difference between the size of the destination
and the number of characters that still fit in, that is using
strncat(dst, src, dst_size);
instead of
strncat(dst, src, dst_size-strlen(dst)-1);
However, if you have to work with people who cannot or do not
want to read and comprehend the function documentation, this is
really just one of the many things which will go wrong.

I guess that he would rather like to pass the overall size of the
destination which is IMO no bad idea at all.
The only question to answer is then whether to make the last
character '\0' if no string terminator was encountered or not.
Cheers
Michael
--
E-Mail: Mine is a gmx dot de address.

[Michael Mair]

Michael Mair wrote:

Lawrence Kirby wrote:

On Tue, 16 Nov 2004 12:36:55 +0100, Charlie Gordon wrote:

...

The case against strtok() is also worth fighting : please stop
teaching newbies
to use functions with flawed semantics like this one or its friends :
gets(),
strncpy(), strncat()...

What's wrong with strncat()?

He probably refers to Criminally Stupid Behaviour (TM), such as
ignoring the difference between the size of the destination
and the number of characters that still fit in, that is using
strncat(dst, src, dst_size);
instead of
strncat(dst, src, dst_size-strlen(dst)-1);
However, if you have to work with people who cannot or do not
want to read and comprehend the function documentation, this is
really just one of the many things which will go wrong.

I guess that he would rather like to pass the overall size of the
destination which is IMO no bad idea at all.
The only question to answer is then whether to make the last
character '\0' if no string terminator was encountered or not.

Misleading: I mean in the destination (that is
strlen(dst)>= the passed size)


Cheers
Michael

--
E-Mail: Mine is a gmx dot de address.