Segmentation fault when compiled binary is executed

Discussion in 'C Programming' started by nae zot bba la, Jan 10, 2006.

  1. Hi, very short code here. Basically I want to open a file called
    instruction in a++ mode and then write data of %s type to it, then read
    from the same file and print to screen. The code compiles but when I
    execute the binary and enter some string to expect the program to print
    them for me to screen, segmentation fault occurs. Any ideas anyone?

    #include <stdio.h>
    #include <stdlib.h>

    char *add;
    char *show;
    FILE *instruction;

    main()
    {
    scanf("%s",&add);
    instruction=fopen("instruction","a++");
    fwrite(add,sizeof(add),1,instruction);
    fscanf(instruction,"%s",&show);
    printf("%s",show);
    fcloseall();
    }
    nae zot bba la, Jan 10, 2006
    #1
    1. Advertising

  2. nae zot bba la

    Guest

    You should allocate memory for add and show first. BTW, you should
    close the file and then open it with read mode to get the string
    printed out.
    , Jan 10, 2006
    #2
    1. Advertising

  3. nae zot bba la said:

    > Hi, very short code here. Basically I want to open a file called
    > instruction in a++ mode


    There is no such mode. You may be thinking of "a+" or "a+b".

    > and then write data of %s type to it,


    But there is no such type. You may be thinking of "sequence of char
    terminated by the first null character", which is also known as "string" -
    and this is not a data type but a data format.

    > then read
    > from the same file and print to screen. The code compiles but when I
    > execute the binary and enter some string to expect the program to print
    > them for me to screen, segmentation fault occurs. Any ideas anyone?
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > char *add;
    > char *show;
    > FILE *instruction;
    >
    > main()


    Aside: the preferred form of main(), when taking no arguments, is:

    int main(void)

    but this is not the cause of your seg fault.

    > {
    > scanf("%s",&add);


    Quite apart from the hazards involved in using %s with scanf, and quite
    apart from the fact that you appear to be ignoring an extremely useful
    value returned by scanf, there is also the problem that scanf not only
    requires char * rather than char ** as its argument but also requires that
    pointer to be pointing to sufficient storage to receive the data in
    question. This is almost certainly the cause of your seg fault. Well, it's
    the cause of /this/ seg fault, anyway. Once you've fixed it, I fully expect
    you to get others.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jan 10, 2006
    #3
  4. thx. so basically somethign like

    add=malloc(sizeof(a));
    show=malloc(sizeof(s));
    nae zot bba la, Jan 10, 2006
    #4
  5. nae zot bba la said:

    > thx. so basically somethign like
    >
    > add=malloc(sizeof(a));
    > show=malloc(sizeof(s));


    Whilst the above changes will indeed stop you from getting a segmentation
    fault, this is only because they will instead give you compilation errors.

    Please find a good C book, one that explains about storage, and read it very
    closely until you get the hang of - at least - the following facts:

    1) Everything has to be Somewhere. Every single character you need to store
    requires a byte of storage in which to be stored.
    2) Types *matter*.
    3) The malloc function can return NULL.


    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at above domain (but drop the www, obviously)
    Richard Heathfield, Jan 10, 2006
    #5
  6. nae zot bba la

    Mike Wahler Guest

    "nae zot bba la" <> wrote in message
    news:p...
    > Hi, very short code here. Basically I want to open a file called
    > instruction in a++ mode and then write data of %s type to it, then read
    > from the same file and print to screen. The code compiles but when I
    > execute the binary and enter some string to expect the program to print
    > them for me to screen, segmentation fault occurs. Any ideas anyone?
    >
    > #include <stdio.h>
    > #include <stdlib.h>
    >
    > char *add;
    > char *show;
    > FILE *instruction;


    There's no reason for these objects to be defined at file scope.

    >
    > main()


    int main(void)

    > {
    > scanf("%s",&add);


    Undefined behavior.

    > instruction=fopen("instruction","a++");


    Undefined behavior.

    > fwrite(add,sizeof(add),1,instruction);


    Undefined behavior.

    > fscanf(instruction,"%s",&show);


    Undefined behavior.

    > printf("%s",show);


    Undefined behavior.

    > fcloseall();


    No such function in standard C.

    return 0;

    > }


    You don't have a C text, do you? (If you do, you need much more study. If
    you
    don't, get one. See the reviews at www.accu.org for suggestions).

    -Mike
    Mike Wahler, Jan 10, 2006
    #6
  7. nae zot bba la, Jan 10, 2006
    #7
  8. nae zot bba la <> wrote:

    > MKW, i will go and read this from chapter 1 to the end.
    > http://publications.gbdirect.co.uk/c_book/chapter1/form_of_a_c_program.html


    That seems like a much better resource than a lot of the supposed
    tutorials to be found online, but it still is inferior to the K&R2
    text (which you should purchase if you have the means to do so).
    I spotted a few instances (I imagine more exist) where a C guru
    (I am not one) would have cause to quibble:

    1) int main() isn't incorrect, but int main( void ) is generally
    preferable.

    2) Ending main() with a call to exit( EXIT_SUCCESS ) isn't incorrect
    either, but it isn't great style. return EXIT_SUCCESS is much more
    conventional.

    3) The language in 5.4.1 fails to describe "FOO" as a string literal
    and therefore leaves the distinction between them and "ordinary"
    strings unclear.

    4) "The rules for assignment of pointers show that there is no need to
    use a cast on the return value from malloc, but it is often done in
    practice."

    This statement might have been accurate in 1991, but it really
    isn't these days. Casting the return value of malloc() is
    generally discouraged.

    In short, you might read the C FAQ along with the resource you cited:

    http://c-faq.com

    and fill in some of the holes.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Jan 11, 2006
    #8
  9. nae zot bba la

    Richard Bos Guest

    Christopher Benson-Manica <> wrote:

    > nae zot bba la <> wrote:
    >
    > > MKW, i will go and read this from chapter 1 to the end.
    > > http://publications.gbdirect.co.uk/c_book/chapter1/form_of_a_c_program.html

    >
    > That seems like a much better resource than a lot of the supposed
    > tutorials to be found online, but it still is inferior to the K&R2
    > text (which you should purchase if you have the means to do so).
    > I spotted a few instances (I imagine more exist) where a C guru
    > (I am not one) would have cause to quibble:


    > 4) "The rules for assignment of pointers show that there is no need to
    > use a cast on the return value from malloc, but it is often done in
    > practice."
    >
    > This statement might have been accurate in 1991, but it really
    > isn't these days. Casting the return value of malloc() is
    > generally discouraged.


    Counter-quibble: yes, it's accurate. Casting malloc() _is_ often done.
    Shouldn't be, but it is.

    Richard
    Richard Bos, Jan 11, 2006
    #9
  10. Christopher Benson-Manica <> writes:
    [...]
    > 2) Ending main() with a call to exit( EXIT_SUCCESS ) isn't incorrect
    > either, but it isn't great style. return EXIT_SUCCESS is much more
    > conventional.


    I don't think I agree. Using exit() is fairly common. I tend to use
    0 rather than EXIT_SUCCESS myself, unless I'm also using EXIT_FAILURE.

    For no particularly good reason, I tend to think of EXIT_SUCCESS and
    EXIT_FAILURE as arguments to exit() rather than as values to be
    return'ed from main().

    "exit(n);" and "return n;" (in main()) are almost exactly equivalent
    anyway, so I don't worry much about which one anyone chooses to use.
    (The only difference is the lifetime of variables local to main()
    referred to indirectly from an atexit()-registered function; any
    program for which this matters is far too obscure anyway.)

    --
    Keith Thompson (The_Other_Keith) <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.
    Keith Thompson, Jan 11, 2006
    #10
  11. Keith Thompson <> wrote:

    > I don't think I agree. Using exit() is fairly common.


    At the end of main()? I accept that your experience is much broader
    than mine, but FWIW I have seen many more return's than exit()'s at
    the end of main().

    > "exit(n);" and "return n;" (in main()) are almost exactly equivalent
    > anyway, so I don't worry much about which one anyone chooses to use.


    I suppose 1991 conventions may have been different; I was 11 at the
    time, so I'm not qualified to comment. In any case, I admit that it
    isn't much more than a question of style religion. Isn't there some
    (negligible) overhead associated with the call to exit() as opposed to
    a straight return, though?

    Clearly, if God had intended exit() to be used instead of a return from
    main(), He would have allowed void main( void ) as a valid prototype :)

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Jan 12, 2006
    #11
  12. >> "exit(n);" and "return n;" (in main()) are almost exactly equivalent
    >> anyway, so I don't worry much about which one anyone chooses to use.

    >
    >I suppose 1991 conventions may have been different; I was 11 at the
    >time, so I'm not qualified to comment. In any case, I admit that it
    >isn't much more than a question of style religion. Isn't there some
    >(negligible) overhead associated with the call to exit() as opposed to
    >a straight return, though?


    Since many implementations use startup code like:

    _start() { exit(main(argc, argv)); }
    (where getting the values of argc and argv is implementation-dependent).

    isn't there some (negligible) overhead associated with the return
    which doesn't happen if you call exit() directly?

    Gordon L. Burditt
    Gordon Burditt, Jan 12, 2006
    #12
  13. Gordon Burditt <> wrote:

    > isn't there some (negligible) overhead associated with the return
    > which doesn't happen if you call exit() directly?


    Sounds like six on one system, half a dozen on another. I was not
    aware of

    > _start() { exit(main(argc, argv)); }


    , so I appreciate the insight.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Jan 12, 2006
    #13
    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. Alex Hunsley
    Replies:
    17
    Views:
    854
  2. Pud
    Replies:
    0
    Views:
    565
  3. Replies:
    0
    Views:
    519
  4. Klaus Schneider
    Replies:
    1
    Views:
    530
    Rolf Magnus
    Dec 2, 2004
  5. lander
    Replies:
    5
    Views:
    581
    bruce barker
    Mar 5, 2008
Loading...

Share This Page