disturbed between two versions

[Une bévue]

I'm still a neby in C, i do have two versions of about the same algo.
The first one works fine but de second. I don't see what's the prob with
the second.

the purpose to cut out in sections a unix path.

the test source :
--- essai_token.c ------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main (void)
{
const char *unix_sep = "/";
char *token = malloc(sizeof (*token) * 256);
if(token == NULL) return EXIT_FAILURE;

//
// Version 1
//
printf("// Version 1\n");
char *path_v1 = strdup("/path_v1/to/something");
printf("path_v1 = %s\n", path_v1);
token = strtok(path_v1, unix_sep);
printf("token = %s\n", token);
while(token != NULL) {
token = strtok(NULL, unix_sep);
printf("token = %s\n", token);
}
free(path_v1);
path_v1 = NULL;
printf("\n");

//
// Version 2
//
printf("// Version 2\n");
char *path_v2 = malloc(sizeof (*path_v2) * 256);
if(path_v2 == NULL) return EXIT_FAILURE;
path_v2 = "/path_v2/to/something";
printf("path_v2 = %s\n", path_v2);
token = strtok(path_v2, unix_sep);// <= broken HERE
printf("token = %s\n", token);
while(token != NULL) {
token = strtok(NULL, unix_sep);
printf("token = %s\n", token);

}
free(path_v2);
path_v2 = NULL;
free(token);
token = NULL;
return EXIT_SUCCESS;
}
------------------------------------------------------------------------

run output :

~/work/C/developpez/listes_chainees _double%./essai_token
// Version 1
path_v1 = /path_v1/to/something
token = path_v1
token = to
token = something
token = (null)

// Version 2
path_v2 = /path_v2/to/something
zsh: bus error ./essai_token

then, the broken line is "token = strtok(path_v2, unix_sep);"

no warnings nor errors at the compil time using the following gcc
options :

alias ycc='cc -W -Wall -Wextra -Wuninitialized -Wstrict-prototypes
-Wmissing-prototypes -pedantic -std=c99 -O2 -pipe -o '

pratically i make use only of the first version, however i'd like to
understand what's my mistake in the second one...
i know that working with strtok needs a writable mem zone, i assume
malloc does that ???

my setup :
Mac OS X 10.4.7
~/work/C/developpez/listes_chainees _double%gcc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5363)

--
une bévue

[Keith Thompson]

Mark McIntyre <ma**********@s pamcop.netwrite s:

On Sun, 10 Sep 2006 16:54:42 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgw rote:

>>Mark McIntyre <ma**********@s pamcop.netwrite s:

[...]

>>Note: The = operator does NOT copy. It assigns values - in this case,
it assigns the value of path_p2 (which is a pointer) to be a pointer
to the string "/path_v2/to/something".

Yes, the "=" operator *does* copy.

Ok, I'll bite. For a weak definition of copy, which doen't necessarily
include the result being identical to the original.

Fair enough.

>>(In this case, what it copies is a pointer value, not what it points to.)

Bear in mind that it does not necessarily create a copy of the value,
since the value is type-converted en route if required. (6.5.16.1 p2).

(I admit I left the word "strings" out after the word "copy", but then
strings don't exist in C so it seemed reasonable not to leave it
in...)

Here you lost me. What do you mean by "strings don't exist in C"?
There is no string type, but a string is defined in C99 7.1.1p1 as "a
contiguous sequence of characters terminated by and including the
first null character." Strings certainly do exist in C.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Mon, 11 Sep 2006 04:15:06 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.orgw rote:

>Here you lost me. What do you mean by "strings don't exist in C"?

I meant that there's no string type, unlike in certain other
languages.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan