Unitialized pointers?

Discussion in 'C Programming' started by Greg, Oct 11, 2004.

  1. Greg

    Greg Guest

    Please take a look at

    #include <stdio.h>

    int main() {
    char *cstring;
    FILE *fp;
    fp = fopen( "proc.rc", "r" );
    fscanf(fp,"%s", cstring);
    printf("%s", cstring);

    return 0;
    }

    The above code works on Utopia (Sun OS 5.7) and on Saturn (Linux 2.6.7)
    but it seg faults on artoo (FreeBSD 4.10) and on arcadia (NetBSD 1.6.1)


    So, I changed *cstring to an array of 100 chars like so...

    #include <stdio.h>

    int main() {
    char cstring[100];
    FILE *fp;
    fp = fopen( "proc.rc", "r" );
    fscanf(fp,"%s", cstring);
    printf("%s", cstring);

    return 0;
    }

    ....and this code works flawlessly on all platforms. I'm having trouble
    explaining the cause of this to a friend. He believes Linux, Sun OS and
    even NetBSD 2 magically allocate memory on the fly (this is speculation
    so far). I don't believe that's standard in the C language to depend on
    such facilities. My understanding is that *cstring is uninitialized and
    shouldn't be assigned segments of data unless it points to an allocated
    space of memory (such as an array or segments allocated by malloc)

    Please clear up ANY misconceptions.

    Thank you,

    -Greg
    Greg, Oct 11, 2004
    #1
    1. Advertising

  2. In article <>,
    Greg <> wrote:

    >The above code works on Utopia (Sun OS 5.7) and on Saturn (Linux 2.6.7)


    Just luck. The pointer must happen to point to some bit of memory,
    and overwriting it must happen not to do any harm. The code is wrong.


    >So, I changed *cstring to an array of 100 chars like so...

    [...]
    >...and this code works flawlessly on all platforms.


    Until you give it a string longer than 99 characters.

    >I'm having trouble explaining the cause of this to a friend.
    >He believes Linux, Sun OS and
    >even NetBSD 2 magically allocate memory on the fly


    Don't rely on this friend for advice about C programming.

    -- Richard
    Richard Tobin, Oct 11, 2004
    #2
    1. Advertising

  3. Greg wrote:

    > Please take a look at
    >
    > #include <stdio.h>
    >
    > int main() {
    > char *cstring;
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);
    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > The above code works on Utopia (Sun OS 5.7) and on Saturn (Linux 2.6.7)


    By accident.

    > but it seg faults on artoo (FreeBSD 4.10) and on arcadia (NetBSD 1.6.1)


    As is reasonable, since you have allocated no space to which cstring points.

    >
    >
    > So, I changed *cstring to an array of 100 chars like so...
    >
    > #include <stdio.h>
    >
    > int main() {
    > char cstring[100];
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);
    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > ...and this code works flawlessly on all platforms. I'm having trouble
    > explaining the cause of this to a friend. He believes Linux, Sun OS and
    > even NetBSD 2 magically allocate memory on the fly (this is speculation
    > so far). I don't believe that's standard in the C language to depend on
    > such facilities.


    It's not only not standard, it doesn't happen. If the code you posted
    accidentally "works." it is because cstring happens to accidentally
    point to some space that accidentally doesn't cause some problem like
    segfaulting. Or overwriting part of the OS.
    Martin Ambuhl, Oct 11, 2004
    #3
  4. Greg wrote:
    > Please take a look at
    >
    > #include <stdio.h>
    >
    > int main() {
    > char *cstring;
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);


    This results in *UB* - Undefined Behaviour.

    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > The above code works on Utopia (Sun OS 5.7) and on Saturn (Linux 2.6.7)
    > but it seg faults on artoo (FreeBSD 4.10) and on arcadia (NetBSD 1.6.1)
    >
    >
    > So, I changed *cstring to an array of 100 chars like so...
    >
    > #include <stdio.h>
    >
    > int main() {
    > char cstring[100];
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);


    Fine.

    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > ...and this code works flawlessly on all platforms. I'm having trouble
    > explaining the cause of this to a friend. He believes Linux, Sun OS and
    > even NetBSD 2 magically allocate memory on the fly (this is speculation
    > so far).


    There is no reason to believe this is true.
    Well, even if case 1 works on platform X, it is still a particular
    form of *UB*.

    >I don't believe that's standard in the C language to depend on
    > such facilities. My understanding is that *cstring is uninitialized and
    > shouldn't be assigned segments of data unless it points to an allocated
    > space of memory (such as an array or segments allocated by malloc)
    >


    The runtime is not going to do automatic initialization of
    memory. It would just obey the programmer.
    For a malloc , it would allocate memory and return a pointer to the
    same.
    And given a pointer to memory to free (that is already allocated),
    it would free the memory. This is what a runtime is obliged to do.
    Any violation of this would result in *UB* (say, for example -
    freeing the pointer pointing to a location twice )- which means you
    cannot explain the behaviour and anything can happen then.


    --
    Karthik. http://akktech.blogspot.com .
    ' Remove _nospamplz from my email to mail me. '
    ------------ And now a word from our sponsor ------------------
    Do your users want the best web-email gateway? Don't let your
    customers drift off to free webmail services install your own
    web gateway!
    -- See http://netwinsite.com/sponsor/sponsor_webmail.htm ----
    Karthik Kumar, Oct 11, 2004
    #4
  5. On Mon, 11 Oct 2004 00:23:53 +0000, Greg wrote:

    > ...and this code works flawlessly on all platforms. I'm having trouble
    > explaining the cause of this to a friend. He believes Linux, Sun OS and
    > even NetBSD 2 magically allocate memory on the fly (this is speculation
    > so far). I don't believe that's standard in the C language to depend on

    If so, you'd probably have to pass it &cstring to make any sense.
    The code works only by pure luck though.

    You could take a look at the assembly code to see what's going on..
    > such facilities. My understanding is that *cstring is uninitialized and
    > shouldn't be assigned segments of data unless it points to an allocated
    > space of memory (such as an array or segments allocated by malloc)
    =?iso-8859-1?q?Nils_O=2E_Sel=E5sdal?=, Oct 11, 2004
    #5
  6. Greg

    bd Guest

    Greg wrote:

    > Please take a look at
    >
    > #include <stdio.h>
    >
    > int main() {
    > char *cstring;
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);
    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > The above code works on Utopia (Sun OS 5.7) and on Saturn (Linux 2.6.7)
    > but it seg faults on artoo (FreeBSD 4.10) and on arcadia (NetBSD 1.6.1)
    >
    >
    > So, I changed *cstring to an array of 100 chars like so...
    >
    > #include <stdio.h>
    >
    > int main() {
    > char cstring[100];
    > FILE *fp;
    > fp = fopen( "proc.rc", "r" );
    > fscanf(fp,"%s", cstring);
    > printf("%s", cstring);
    >
    > return 0;
    > }
    >
    > ...and this code works flawlessly on all platforms. I'm having trouble
    > explaining the cause of this to a friend. He believes Linux, Sun OS and
    > even NetBSD 2 magically allocate memory on the fly (this is speculation
    > so far). I don't believe that's standard in the C language to depend on
    > such facilities. My understanding is that *cstring is uninitialized and
    > shouldn't be assigned segments of data unless it points to an allocated
    > space of memory (such as an array or segments allocated by malloc)
    >
    > Please clear up ANY misconceptions.


    The use of *cstring in the first example results in undefined behavior. As
    far as I know, none of Linux, Sun OS, or NetBSD 2 allocate memory on the
    fly, nor do any other C implementations that I know of. If that first
    example worked, it was a coincidence, and likely would result in a crash
    later, as it would be writing in some random memory address that's likely
    needed for something else.
    bd, Oct 11, 2004
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Darrell Grainger

    Re: Unitialized Memory Read In sscanf()

    Darrell Grainger, Jun 24, 2003, in forum: C Programming
    Replies:
    1
    Views:
    809
    Alan Balmer
    Jun 24, 2003
  2. Eric Sosman

    Re: Unitialized Memory Read In sscanf()

    Eric Sosman, Jun 24, 2003, in forum: C Programming
    Replies:
    0
    Views:
    837
    Eric Sosman
    Jun 24, 2003
  3. Adam Monsen
    Replies:
    3
    Views:
    242
    =?iso-8859-1?Q?Fran=E7ois?= Pinard
    Sep 9, 2005
  4. Replies:
    2
    Views:
    294
  5. Michael Linfield

    Ruport::DataSet unitialized constant?

    Michael Linfield, Aug 15, 2007, in forum: Ruby
    Replies:
    1
    Views:
    110
    Stefan Mahlitz
    Aug 15, 2007
Loading...

Share This Page