Segfault in an if

Discussion in 'C Programming' started by Emmanuel Delahaye, Jul 17, 2004.

  1. H.A. Sujith vient de nous annoncer :
    > The following code is causing a segfault at the first if statement.
    > Am I doing something wrong or is it a compiler bug?
    >
    > //----------
    > #include <stdio.h>
    >
    > int main(int argc, char *argv[])
    > {
    > int c;
    > FILE *inp;
    >
    > if(argc > 2) {


    Do you mean here ?

    > printf("Too many arguments\n");
    > return 1;
    > } else if(argc > 1)
    > if((inp = fopen(argv[1], "r")) == NULL) {
    > printf("error: unable to open file %s\n", argv[1]);
    > return 2;
    > }
    > else
    > inp = stdin;
    > //..


    Sounds good to me. Might be something else (try to rebuild all) or a
    compiler's bug. Try with another one.
    Emmanuel Delahaye, Jul 17, 2004
    #1
    1. Advertising

  2. Emmanuel Delahaye

    H.A. Sujith Guest

    The following code is causing a segfault at the first if statement.
    Am I doing something wrong or is it a compiler bug?

    //----------
    #include <stdio.h>

    int main(int argc, char *argv[])
    {
    int c;
    FILE *inp;

    if(argc > 2) {
    printf("Too many arguments\n");
    return 1;
    } else if(argc > 1)
    if((inp = fopen(argv[1], "r")) == NULL) {
    printf("error: unable to open file %s\n", argv[1]);
    return 2;
    }
    else
    inp = stdin;
    //..

    --
    mail to: randomzoo <at> spymac <dot> com
    H.A. Sujith, Jul 17, 2004
    #2
    1. Advertising

  3. Emmanuel Delahaye

    George Huber Guest

    On Sat, 17 Jul 2004 10:16:33 -0700, H.A. Sujith wrote:

    > The following code is causing a segfault at the first if statement.
    > Am I doing something wrong or is it a compiler bug?
    >
    > //----------
    > #include <stdio.h>
    >
    > int main(int argc, char *argv[])
    > {
    > int c;
    > FILE *inp;
    >
    > if(argc > 2) {
    > printf("Too many arguments\n");
    > return 1;
    > } else if(argc > 1)
    > if((inp = fopen(argv[1], "r")) == NULL) {
    > printf("error: unable to open file %s\n", argv[1]);
    > return 2;
    > }
    > else
    > inp = stdin;
    > //..


    The following compiles and runs on my system (fedora core 2, gcc 3.3.3).
    I would suspect that you have not found a compiler bug - printf is far
    to common for behavior like this not to have been caught before.

    int main(int argc, char** argv)
    {
    if(argc > 2)
    {
    printf("To many arguments\n");
    return 1;
    }
    else
    {
    if(2 == argc)
    {
    printf("opening a file\n");
    }
    else
    {
    printf("redirecting stdin\n");
    }
    }

    return 0;
    }

    Try doing a full recompilation, including manually removing any object
    files, libraries and the like. If you still get an error, try running the
    program under a debugger to see where you are actually seg-faulting.

    Finally, as a side note, I use exit() to return from main not return. I
    can not see this making any difference at all, but it is something that
    you could try.

    Hope this helps, if not try to provide more information - stack trace and
    the like.

    George
    George Huber, Jul 17, 2004
    #3
  4. H.A. Sujith wrote:

    > The following code is causing a segfault at the first if statement.
    > Am I doing something wrong or is it a compiler bug?
    >
    > //----------
    > #include <stdio.h>
    >
    > int main(int argc, char *argv[])
    > {
    > int c;
    > FILE *inp;
    >
    > if(argc > 2) {
    > printf("Too many arguments\n");
    > return 1;
    > } else if(argc > 1)
    > if((inp = fopen(argv[1], "r")) == NULL) {
    > printf("error: unable to open file %s\n", argv[1]);
    > return 2;
    > }

    HERE is the error!
    this else behind is all about the if just above it.
    not the else if, so when argc == 1, inp isnt initialized
    the correction would be:
    else if(argc > 1) {
    if(...) {
    }
    }
    else
    inp = stdin;
    > else
    > inp = stdin;
    > //..
    >




    --
    Felipe Magno de Almeida
    Ciencia da Computacao - Unicamp
    - UIN: 146989862
    Cause Rock and Roll can never die.
    "if you want to learn something really well, teach it to a computer."
    What is Communism?
    Answer: "Communism is the doctrine of the conditions of the liberation
    of the proletariat." (by Karl Marx)
    Felipe Magno de Almeida, Jul 17, 2004
    #4
  5. Emmanuel Delahaye

    Michael Guest

    "H.A. Sujith" <> wrote in message news:<>...
    > The following code is causing a segfault at the first if statement.
    > Am I doing something wrong or is it a compiler bug?
    >
    > //----------
    > #include <stdio.h>
    >
    > int main(int argc, char *argv[])
    > {
    > int c;
    > FILE *inp;
    >
    > if(argc > 2) {
    > printf("Too many arguments\n");
    > return 1;
    > } else if(argc > 1)
    > if((inp = fopen(argv[1], "r")) == NULL) {
    > printf("error: unable to open file %s\n", argv[1]);
    > return 2;
    > }
    > else
    > inp = stdin;
    > //..


    you sure it isn't the inp=stdin. That is not allowable you have to
    close the file then fopen it again. I know it isn't the first or the
    second one, both are correct.
    Michael, Jul 17, 2004
    #5
  6. Emmanuel Delahaye

    Chris Torek Guest

    >"H.A. Sujith" <> wrote in message
    >news:<>...

    [snippage]

    >> ... else if(argc > 1)
    >> if((inp = fopen(argv[1], "r")) == NULL) {
    >> printf("error: unable to open file %s\n", argv[1]);
    >> return 2;
    >> }
    >> else
    >> inp = stdin;


    In article <>
    Michael <> writes:
    >you sure it isn't the inp=stdin. That is not allowable you have to
    >close the file then fopen it again.


    This claim is incorrect: "inp = stdin" is allowed, and sets the
    "FILE *" object named "inp" to point to the same "FILE" object that
    the name "stdin" refers to. (The "stdin" name is required to be
    a macro, and might be defined as something like __stdin or &__sfiles[0]
    or some such, but whatever the macro expands to must also have type
    "FILE *" and point to a "FILE" object that ultimately refers to
    the standard input.)

    There is, however, an obvious bug in the code fragment remaining in
    ">>" above:

    if (a)
    if (b)
    c();
    else
    d();

    is improperly indented, and does not mean what it seems to suggest at
    first glance. Fixing the indenting results in:

    if (a)
    if (b)
    c();
    else
    d();

    In other words, the "inp = stdin" assignment occurs only if argc > 1
    *and* the fopen() call succeeds.

    If the fopen() call does succeed, the reference to the underlying
    FILE object is lost when "inp = stdin" overwrites the non-NULL "inp".
    If argc <= 1, the variable "inp" remains uninitialized.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Jul 17, 2004
    #6
  7. George Huber <> wrote in message news:<>...
    > On Sat, 17 Jul 2004 10:16:33 -0700, H.A. Sujith wrote:


    <snip>

    >
    > Finally, as a side note, I use exit() to return from main not return. I
    > can not see this making any difference at all, but it is something that
    > you could try.



    You were doing fine until you said this. Please do not mislead the
    youth. Quoth the standard:


    5.1.2.2.3 Program termination

    1. If the return type of the main function is a type compatible with
    int, a return from the initial call to the main function is equivalent
    to calling the exit function with the value returned by the main
    function as its argument [...]


    Mark F. Haigh
    Mark F. Haigh, Jul 19, 2004
    #7
  8. > HERE is the error!
    > this else behind is all about the if just above it.


    eep

    The lesson here is: Use emacs because it makes these problems obvious.
    Anthony Roberts, Jul 19, 2004
    #8
  9. (Mark F. Haigh) writes:
    > George Huber <> wrote in message
    > news:<>...
    > > On Sat, 17 Jul 2004 10:16:33 -0700, H.A. Sujith wrote:

    >
    > <snip>
    >
    > >
    > > Finally, as a side note, I use exit() to return from main not return. I
    > > can not see this making any difference at all, but it is something that
    > > you could try.

    >
    >
    > You were doing fine until you said this. Please do not mislead the
    > youth. Quoth the standard:
    >
    >
    > 5.1.2.2.3 Program termination
    >
    > 1. If the return type of the main function is a type compatible with
    > int, a return from the initial call to the main function is equivalent
    > to calling the exit function with the value returned by the main
    > function as its argument [...]


    But I think the equivalence breaks down in some obscure circumstances
    involving atexit().

    --
    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, Jul 19, 2004
    #9
  10. In article <>,
    Mark F. Haigh <> wrote:
    ....
    >> Finally, as a side note, I use exit() to return from main not return. I
    >> can not see this making any difference at all, but it is something that
    >> you could try.

    >
    >
    >You were doing fine until you said this. Please do not mislead the
    >youth. Quoth the standard:
    >
    >
    >5.1.2.2.3 Program termination
    >
    >1. If the return type of the main function is a type compatible with
    >int, a return from the initial call to the main function is equivalent
    >to calling the exit function with the value returned by the main
    >function as its argument [...]


    I'm sorry. Your point was?

    If your point is: In a conforming implementation, there shouldn't be any
    difference between them (and thus to imply that you shouldn't even consider
    trying to solve your real world problem by trying one when you find that
    the other doesn't do what you want), then, well, you're entitled, but you
    might want to read the next paragraph.

    Perhaps we need to make clear to all prospective posters here (by, at
    a start, putting it in the FAQ) that helping people to solve their real
    world problems is off-topic. Note: I am not saying for a second that there
    is anything wrong with this stance - in fact, I rather like it, for
    a variety of reasons, not least of which that it tends to keep the quality
    level of the discussion high.
    Kenny McCormack, Jul 19, 2004
    #10
  11. Kenny McCormack wrote:
    > In article <>,
    > Mark F. Haigh <> wrote:
    > ...
    >
    >>>Finally, as a side note, I use exit() to return from main not return. I
    >>>can not see this making any difference at all, but it is something that
    >>>you could try.

    >>
    >>
    >>You were doing fine until you said this. Please do not mislead the
    >>youth. Quoth the standard:
    >>
    >>
    >>5.1.2.2.3 Program termination
    >>
    >>1. If the return type of the main function is a type compatible with
    >>int, a return from the initial call to the main function is equivalent
    >>to calling the exit function with the value returned by the main
    >>function as its argument [...]

    >
    >
    > I'm sorry. Your point was?


    I don't want any readers thinking that there's some kind of difference
    between using exit and returning a value from main. People posting
    answers here should take care to provide good advice, for the benefit of
    less experienced readers. Changing the return to an exit is not good
    advice in this context, and is not likely to solve or help solve any
    problems.

    >
    > If your point is: In a conforming implementation, there shouldn't be any
    > difference between them (and thus to imply that you shouldn't even consider
    > trying to solve your real world problem by trying one when you find that
    > the other doesn't do what you want), then, well, you're entitled, but you
    > might want to read the next paragraph.
    >
    > Perhaps we need to make clear to all prospective posters here (by, at
    > a start, putting it in the FAQ) that helping people to solve their real
    > world problems is off-topic. Note: I am not saying for a second that there
    > is anything wrong with this stance - in fact, I rather like it, for
    > a variety of reasons, not least of which that it tends to keep the quality
    > level of the discussion high.
    >


    I think that's a bit heavy-handed. As you know, the consensus is that
    people with problems post the smallest strict ANSI C fragment that can
    reproduce the problem. If they can't post a problematic strict ANSI C
    fragment, then they are generally redirected to the newsgroup for their
    target platform.

    Discussions of and questions about portable ANSI C code should not be
    discouraged here. Rather, what should be discouraged (and actively is
    my many regulars) is misleading or incorrect answers to these questions.


    Mark F. Haigh
    Mark F. Haigh, Jul 19, 2004
    #11
  12. Emmanuel Delahaye

    H.A. Sujith Guest

    In article <cdc3f2$r8f$>, Felipe Magno de Almeida wrote:
    > H.A. Sujith wrote:
    >
    >> The following code is causing a segfault at the first if statement.
    >> Am I doing something wrong or is it a compiler bug?
    >>
    >> //----------
    >> #include <stdio.h>
    >>
    >> int main(int argc, char *argv[])
    >> {
    >> int c;
    >> FILE *inp;
    >>
    >> if(argc > 2) {
    >> printf("Too many arguments\n");
    >> return 1;
    >> } else if(argc > 1)
    >> if((inp = fopen(argv[1], "r")) == NULL) {
    >> printf("error: unable to open file %s\n", argv[1]);
    >> return 2;
    >> }

    > HERE is the error!
    > this else behind is all about the if just above it.
    > not the else if, so when argc == 1, inp isnt initialized
    > the correction would be:
    > else if(argc > 1) {
    > if(...) {
    > }
    > }
    > else
    > inp = stdin;


    Thats the problem! I forgot to put the braces.
    (I'm kicking myself in the head with my leg right now, which is very
    difficult BTW). But I still dont understand why my debugger(gdb 5.2)
    said the problem was at line 8, the first 'if'. May be some compiler
    (gcc 3.2) optimization I didn't consider.

    Thanks for the help.

    >> else
    >> inp = stdin;
    >> //..
    >>

    >
    >
    >



    --
    mail to: randomzoo <at> spymac <dot> com
    H.A. Sujith, Jul 19, 2004
    #12
    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. Vedran Vyroubal

    STL string segfault

    Vedran Vyroubal, Mar 3, 2004, in forum: C++
    Replies:
    5
    Views:
    1,336
    Vedran Vyroubal
    Mar 4, 2004
  2. Arthur J. O'Dwyer

    multiset segfault

    Arthur J. O'Dwyer, Jun 17, 2004, in forum: C++
    Replies:
    10
    Views:
    716
    Dave Townsend
    Jun 18, 2004
  3. Jim Strathmeyer

    istream segfault

    Jim Strathmeyer, Jul 22, 2004, in forum: C++
    Replies:
    4
    Views:
    429
    Mike Wahler
    Jul 23, 2004
  4. William Payne
    Replies:
    4
    Views:
    500
    Karthiik Kumar
    Aug 28, 2004
  5. Andrey Vul
    Replies:
    8
    Views:
    685
    Richard Bos
    Jul 30, 2010
Loading...

Share This Page