segfault on strtok

[Dan Pop]

Yeah yeah, alright.

I wonder what they mean by "or such an expression" though...

The obvious: both 0 and (void *)0 are null pointer constants.

Dan

 

[Al Bowers]

On Fri, 24 Oct 2003 12:55:34 +0000, Andreas Kahari wrote:
[cut]

That's the draft standard. I have the book version of the
current standard, but it's at home at the moment. I'll have
to get back to this issue later tonight if noone else has the
current standard at hand and can verify this.

ISO/IEC 9899:1999
6.3.2.3 Pointers
3 An integer constant expression with the value 0, or such an
expressioncast to type void *, is called a null pointer
constant.

Yeah yeah, alright.

I wonder what they mean by "or such an expression" though...

It means an integer constant expression with value 0 that is cast to
type void *.
Exclusive Examples of possible NULL definitions:
(void *)0
(void *)0L
(void *)0LL
or without the cast
0
0L
0LL

 

[The Real OS/2 Guy]

#include <stdio.h>

int main() {
char name[15];
strcpy (name, "ab8bc8cd8ed");

char cur[800];
strcpy (cur, strtok(name, "8"));

while (cur) {

cur is never going to be zero.

printf ("Output: %s\n", cur);
printf ("Stringlength %i\n", strlen(cur));
strcpy(cur,strtok(0, "8"));

(strictly speaking, the zero on that line should be a null
pointer)

printf ("next\n");
}

}

Check the return value of strtok(). It returns NULL when no
more tokens remains. NULL is defined in <stdlib.h>.

ok .. i added the both include-lines, changed
while (cur) {
in
while (cur != NULL) {
and replaced 0 with NULL in subsequenced strtok-func, but it keeps
producing segfaults :-(

I think, the problem causes when while run last time and strtok returns
NULL. Is there anything wrong with strcpy-ing this NULL pointer to var
"cur" ? (see also the output-wrap in first msg of thread)

is strcpy copying the pointer 0xAFFE or copies it the string it points
to?

Why does you thing that strcpy should copy a NULL pointer when it has
to copy the string a pointer points to?

Why does you think that strcpy should not segfault, convert the moon
ino blue cheese, or dimply throw an atimic bomb onto to white house,
as your mashine does does always when you says it to dereference a
NULL pointer?

 

[Mark McIntyre]

0 converted to a pointer *is* a null pointer. There's nothing wrong with
using 0 here.

Technically you're right. However the Standard does say that it wants
a null first argument, and its IMHO idiosyncratic to say the least to
use zero to mean NULL.

 

[Mark McIntyre]

That is a matter of opinion.

But sensible. Why call a it an earth inverting horticultural
implement, when you can deobfuscate your code quite easily by using
handy macros that the Standard supplies?

 

[Sheldon Simms]

But sensible. Why call a it an earth inverting horticultural
implement, when you can deobfuscate your code quite easily by using
handy macros that the Standard supplies?

As a matter of fact I usually do use "NULL", but I don't
find "0" to be any more obscure.

The token "0", consisting of one character, is hardly a fitting
counterpart to "earth inverting horticultural implement".

 

[Mark McIntyre]

As a matter of fact I usually do use "NULL", but I don't
find "0" to be any more obscure.

*shrug*. For me, I find it counterintuitive to say "if pointer is
zero" when I mean "if pointer is a null pointer", since pointers
aren't numbers, they're pointers. Frankly when I see someone comparing
a pointer to zero, the first thing that crosses my mind is "does this
guy realise that pointers are not integers? Hmm. I wonder what else
he's assuming based on some limited experience ?"

The token "0", consisting of one character, is hardly a fitting
counterpart to "earth inverting horticultural implement".

obfuscation is not measured by the length of the words used. Consider
Ben Pfaff's sigblock (or is it Dann Corbit's?), or any IOCCC entry!

 

[Sheldon Simms]

*shrug*. For me, I find it counterintuitive to say "if pointer is
zero" when I mean "if pointer is a null pointer", since pointers
aren't numbers, they're pointers.

It seems like you don't really "get" the fact that

...
char * p;
...
if (p == 0)
...

means exactly "if p is a null pointer" and not "if p is zero"

Frankly when I see someone comparing a pointer to zero, the first
thing that crosses my mind is "does this guy realise that pointers are
not integers?

Since every conforming implementation must interpret every
integer constant expression with the value zero in a pointer
context as a null pointer constant, your feelings are misplaced.

Since
- NULL cannot possibly be defined any other way than as an
integer constant expression with the value zero (possibly
cast to void *), and
- every conforming implementation must interpret every integer
constant expression with the value zero that occurs in a
pointer context as a null pointer constant,
your feelings are misplaced.

-Sheldon

 

[Allin Cottrell]

It seems like you don't really "get" the fact that

...
char * p;
...
if (p == 0)
...

means exactly "if p is a null pointer" and not "if p is zero"


Since every conforming implementation must interpret every
integer constant expression with the value zero in a pointer
context as a null pointer constant, your feelings are misplaced.

Doesn't follow. Just because you are being "clever clever" doesn't
mean that most people using this formulation wouldn't be doing so
out of confusion.

Zero has several aspects in C programming, and the sensible
programmer, who wishes his code to be comprehensible to others,
respects the context:

int n = 0;

char txt[32];
*txt = '\0';

char *p = NULL;

Allin Cottrell.

 

[Mark McIntyre]

It seems like you don't really "get" the fact that

I "get" it perfectly. Its just that zero is an integer, and letting
the compiler implicitly convert it to a void* so that you can compare
to a pointer, while syntactically fine, doesn't sit well with me.

Since every conforming implementation must interpret every
integer constant expression with the value zero
in a pointer context as a null pointer constant,

This is /nothing/ to do with whether its correct C. I know it is and
I've no problem with that. I've a problem with whether people actually
understand whats happening. You don't seem to, for instance, but I may
simply not understand you, or you may be being unclear.

your feelings are misplaced.

Never heard someone say "well, its just an address, which is an
integer, so I can easily stuff it into a long"? I certainly have.

Since
- NULL cannot possibly be defined any other way than as an
integer constant expression with the value zero (possibly
cast to void *), and
- every conforming implementation must interpret every integer
constant expression with the value zero that occurs in a
pointer context as a null pointer constant,
your feelings are misplaced.

Tell that to the people that think pointers are integers.

Anyway, YMMV, HAND, OAO.

 

[Sheldon Simms]

I "get" it perfectly. Its just that zero is an integer, and letting
the compiler implicitly convert it to a void* so that you can compare
to a pointer, while syntactically fine, doesn't sit well with me.

The compiler does the same thing whether or not you use the NULL
macro: It recognizes a null pointer constant and converts it to a
null pointer if used in a pointer context. If not used in a pointer
context, the 0 is an integer constant. Using NULL instead of 0
doesn't affect this at all.

Anyway, YMMV

True.

HAND, OAO.

Roger.

 

[Mark McIntyre]

The compiler does the same thing whether or not you use the NULL
macro:

You miss the point. This is nothing to do with the compiler. The
compiler probably also recognises
int* p = ((long)100000 - (long)pow(10,5));
as meaning "set p to a null pointer"
that doesn't mean to say its a good idea to use this definition of
NULL, purely from a point of view of clarity of code.

 

[Jeremy Yallop]

You miss the point. This is nothing to do with the compiler. The
compiler probably also recognises
int* p = ((long)100000 - (long)pow(10,5));
as meaning "set p to a null pointer"

I doubt it. That doesn't look much an integer constant expression.

Jeremy.

 

[Sheldon Simms]

You miss the point. This is nothing to do with the compiler.

Then why did you mention it?

 

[Mark McIntyre]

I doubt it. That doesn't look much an integer constant expression.

depends how pow is implemented

but you're right. replace pow with 10*10*10*10*10

 

[Mark McIntyre]

Then why did you mention it?

I didn't mention the compiler, you brought that up.

Shall we continue to psephologise?

 

[Sheldon Simms]

Restoring Context...

I didn't mention the compiler, you brought that up.

No I didn't. You said that letting the compiler do a conversion
"doesn't sit well with you". I just pointed out that the compiler
does the same thing whether you use the null pointer constant 0,
or you use the macro NULL, because the macro NULL contains a
null pointer constant with the textual representation "0".

Shall we continue to psephologise?

Well since we aren't psephologizing (if there is such a word),
we can't continue. Why would we want to study elections in
comp.lang.c anyway?

 

[Mark McIntyre]

Restoring Context...



No I didn't. You said that letting the compiler do a conversion
"doesn't sit well with you".

So? I didn't say that my point had anything to do with the compiler.

I just pointed out

yada yada. Nobody's listening to us.

We disagree, I happen to think that its needlessly obfuscating to use
zero to mean a null pointer when there's a perfectly good macro
provided for it. You disagree for no obvious reason I can discern.
Enough.

Well since we aren't psephologizing (if there is such a word),
we can't continue. Why would we want to study elections in
comp.lang.c anyway?

Perhaps filibustering is closer to the mark. We're both trying to talk
the other into the ground, without actually forcing any conclusion,
because there /is/ no conclusion.

 

[Irrwahn Grausewitz]

Sheldon Simms <[email protected]> wrote:

yada yada. Nobody's listening to us.

Not true, it's kind of amusing. ;-)

Perhaps filibustering is closer to the mark.

<snip>

And one can learn interesting words, too. ;-)

 

[Sheldon Simms]

Not true, it's kind of amusing. ;-)

And besides, the thread reaches only halfway to the
the right side of the window. It would be a shame to
quit now...