[comp.lang.c] NULL pointer problem on SUN

theruska@digi.lonestar.org (Thomas Heruska) (11/10/90)

I am having trouble using the function strtok on a SUN.  The function
works perfectly on an HP and APOLLO system, so I am convinced that it is   
a specific SUN problem.  

I believe that the problem occurs due to the fact strtok returns a NULL 
pointer when it encounters the end of the string it is parsing.  I am trying
to copy this NULL pointer to another string and check that string for the NULL.
For some reason, it crashes at this point ONLY on the Sun.  Has anyone 
encountered this problem before?  It is obviously not a problem with strtok, but
rather with copying a NULL pointer to a string.  The man pages on strtok state
that a pointer to a null string must be used instead of a NULL pointer on the
Sun.  However, strtok only returns a NULL pointer.  I have tried casting
(char *) to the returned value from strtok, but it produces the same results.


   portion of code: 

   char token[50];
   char mesg[50];

   strcpy(mesg," \0");

   strcpy(token,strtok(mesg," \0"));    /* crashes here - should place
                                              a NULL pointer in token   */
   if (token[0] == NULL) 
       . 
       .
       .


Does anyone know how to get around this on a SUN?  

Please E-mail any suggestions.  Thanks in advance.

gwyn@smoke.brl.mil (Doug Gwyn) (11/10/90)

In article <1255@digi.lonestar.org> theruska@digi.lonestar.org (Thomas Heruska) writes:
>I am having trouble using the function strtok on a SUN.  The function
>works perfectly on an HP and APOLLO system, so I am convinced that it is   
>a specific SUN problem.  

No, it's incorrect code on your part.

>   strcpy(token,strtok(mesg," \0"));    /* crashes here - should place
>                                              a NULL pointer in token   */

strcpy() requires valid source and destination pointer arguments.
A null pointer doesn't point anywhere.  Therefore it cannot be used
to fetch a 0-char-terminated array of bytes from the source location.

On systems where this APPEARS to work, it is only because on those
systems there happens to be something innocuous (probably starting
with a 0 byte value) at virtual address 0, and when strcpy() tries
to use the pointer you supplied to it, it looks just like address 0.

You should fix the code.  Null pointers don't point anywhere.

mills@ccu.umanitoba.ca (Gary Mills) (11/11/90)

In <1255@digi.lonestar.org> theruska@digi.lonestar.org (Thomas Heruska) writes:

>I believe that the problem occurs due to the fact strtok returns a NULL 
>pointer when it encounters the end of the string it is parsing.  I am trying
>to copy this NULL pointer to another string and check that string for the NULL.

You have a serious misconception about NULL.  A NULL pointer does not point to
a null character.  In fact, a NULL pointer does not point at all.  Neither is
a NULL pointer the same as a null string.  When you have a pointer that you
suspect may be NULL, you must test the pointer before referring to the object
at which the pointer points.  This way should work on all the machines:

   char token[50];
   char mesg[50];
   char *ptr;

   strcpy(mesg," \0");

   ptr = strtok(mesg," \0");
   if ( ptr != NULL ) {
       strcpy(token, ptr);
       . 
       .
       .

-- 
-Gary Mills-         -Networking Group-          -U of M Computer Services-

djones@megatest.UUCP (Dave Jones) (11/16/90)

From article <1255@digi.lonestar.org>, by theruska@digi.lonestar.org (Thomas Heruska):

> For some reason, it crashes at this point ONLY on the Sun.  Has anyone 
> encountered this problem before?  It is obviously not a problem with
> strtok, but rather with copying a NULL pointer to a string.

"Obviously", the problem is in the program itself, not the Sun software.

There is no such thing as "copying a NULL pointer to a string."
Get yourself a copy of _The C Programming Language_ by Kerninghan and
Ritchie, and read the chapter on "Pointers and Arrays".

The reason your program worked on the other computer was no doubt
due to coincidences: On that machine, the NULL pointer happens to be
a valid machine address; the hardware does not trap program acesss to
that address as an bus-error; and at that address there just happens to
be a zero-byte. Because there is so much software in existence that works
only because of that coincidence, and because the NULL pointer is often
assumed to be address zero, most vendors whose machine-architecture's
will allow it put a zero in byte zero. But on some machines, you just
can't do that. Address zero often has a special purpose, so you are
constrained on what can be stored there. On many machines, address zero is
not even part of an application program's address-space.