An access violation error happens as a result of this code, is it because
that gets trys to store the information at a
offset of zero?
if not may i get an explanation.
 thx js

#include<stdio.h>

int main(void)
{

  char *str = NULL;

gets(str);

printf("%s",str);

return 0;

char str[128];
fgets(str, sizeof(str), stdin);

or

#include <stdlib.h>

char *str = malloc(128);
if(str)
{
   fgets(str, 128, stdin);
...
   free(str);

--
-----------------------------------------


-----------------------------------------

#include<stdio.h>

int main(void)
{
/* You tried to assign NULL to a memory location  where *str points to,
but  */
/* no memory location was assigned to it.  This is what could be
done:       */

char *str;

if((str=malloc(81))==NULL)
        {
        fprintf(stderr, "Shit, out of memory");
        exit(1);
        }

gets(str);
printf("%s",str);

return 0;

Another thing:
        *str does point to a memory location, you just don't know where.  This
is your access violation.  You should not write to a memory location
that does not belong to your program.  You could wipe out part of your
operating system.  :-(

and obviously does not assign NULL to a memory location where *str
points to. Memory _is_ assigned to str, and the above statement is
a valid initialization, just as in "int fred = 2;".

Wrong diagnosis, right cure:

--
| Kurt Watzka                             Phone : +49-89-2180-6254

                gets(temp_str);
                str = (char *) malloc(strlen(temp_str) + 1);
                strcpy(str,temp_str);

                where max_length is the maximum number char you can
                have.
                You need <string.h> for strcpy
                + 1 is for the null byte.

Good luck,

Operating systems provide protection schemes which prevent exactly this problem.

--

``Not only is UNIX dead, it's starting to smell really bad.'' -- rob

# I am also curious if a pointer set to null is still considered uninitialized

Of course it is initialized. Initialized (IMHO) means "has been assigned a
value which I can tell" as opposed to "indeterminate, which I can't tell",
like in unitialized automatic variables.

Null pointers may be sanely passed to a lot of functions (fflush,
realloc, system, ...) Null pointers are conceptually pointers
guaranteed not to point to any other object. This property makes
them so useful as an "out-of-band" indicator for pointers.

Regards,

        Jens
--
Jens Schweikhardt  http://www.uni-stuttgart.de/People/schweikhardt/home.html
SIGSIG -- signature too long (core dumped)

    "Each of the following statements applies unless explicity
     stated otherwise in the detailed descriptions that follow.

[That is an important clause which tripped me up when I first began
repling to your post.] :-)

    If an argument to a function has an invalid value (such as a
    value outside the domain of the function, or a pointer outside
    the address space of the program, or a null pointer), the
    behavior is undefined."

So, some library functions can be called with a null pointer *if
explicitly stated* in their description.

I know that the above applies to the standard library, but is it ok
to call your own functions with a null pointer? It seems if you had
a function that validated a region of memory, handling getting tossed
a null pointer would be expected behavior. The distinction would be
it *is* ok to call non standard library functions with null pointers,
however, about all you could do with them is test for NULL.

[Refering back to my origional post...]
gets, for example, expects to get a pointer to some valid storage. By
setting a pointer to NULL, it is initialized -- but it has not been set
to point to valid storage. (Mixing those two concepts up is what lead
to my silly statement about a NULL pointer perhaps being unitialized.
*Yes*, it is initialized, but *no*, it doesn't point to anything. *That*
is the actual state of affairs.)

--
Craig

Manchester, NH
So what? I got my hands dirty to achieve our goal. -- Paul Mesken

[zap]

# >Null pointers may be sanely passed to a lot of functions (fflush,
# >realloc, system, ...)
#
# That is true, in 7.1.7 we read
#
#     "Each of the following statements applies unless explicity
#      stated otherwise in the detailed descriptions that follow.
[zap]
#     If an argument to a function has an invalid value (such as a
#     value outside the domain of the function, or a pointer outside
#     the address space of the program, or a null pointer), the
#     behavior is undefined."
#
# So, some library functions can be called with a null pointer *if
# explicitly stated* in their description.
#
# I know that the above applies to the standard library, but is it ok
# to call your own functions with a null pointer?

It definitely should be.

# It seems if you had
# a function that validated a region of memory, handling getting tossed
# a null pointer would be expected behavior. The distinction would be
# it *is* ok to call non standard library functions with null pointers,
# however, about all you could do with them is test for NULL.

Do you mean that I'm getting undefined behaviour with

#include <stdio.h>

void foo (void *p)
{
  if (p == NULL) {
    printf ("Got NULL (%p), core meltdown sequence initiated.\n", (void *)p);
  else {
    printf ("Got something non-NULL (%p), all engines running.\n", (void *)p);
  }

        Jens
--
Jens Schweikhardt  http://www.uni-stuttgart.de/People/schweikhardt/home.html
SIGSIG -- signature too long (core dumped)

If a null pointer gets abused in some manner inside of a function,
and you call that function with a null pointer, that would result in
whatever consequences being incurred when you called the function,
including undefined behavior. You could argue that the offending
behavior occurs in the function, and not with the call. If you declare
a pointer as null and then use it in a bad fashion, is the declaration
invoking undefined behavior, or the pointer use? Clearly it is ok to
declare a pointer as being null. However, if the very next statement
hands it off to gets, you have problem with the call to gets, not the
declaration.

So, blah(NULL) could be proven to invoke undefined behavior with some
source code analysis tool, but the language would accept the call as
valid (I think this is what you are wondering my feelings about).

--
Craig

Manchester, NH
So what? I got my hands dirty to achieve our goal. -- Paul Mesken

--
-----------------------------------------


-----------------------------------------

     if (ptr == NULL) {   /* Oops that should have been != */
        *ptr = 'X';
     }

The bug is in the first line but any undefined behaviour will occur in the
second.

--
-----------------------------------------


-----------------------------------------