printing error messages

Discussion in 'C Programming' started by gsa, May 30, 2008.

  1. gsa

    gsa Guest

    Hi,
    I am new to C so please bear with my stupid questions. I am
    trying to open a file to write, but the code complains that it is
    unable to do so. How do I get C to print the reason it is failing?
    Something like the $! function in perl. Thanks a lot for all your
    help.
     
    gsa, May 30, 2008
    #1
    1. Advertising

  2. gsa

    Guest

    In article <>,
    gsa <> wrote:
    >Hi,
    > I am new to C so please bear with my stupid questions. I am
    >trying to open a file to write, but the code complains that it is
    >unable to do so. How do I get C to print the reason it is failing?
    >Something like the $! function in perl. Thanks a lot for all your
    >help.


    perror() may be what you're looking for.
    I don't believe fopen is required to set errno when it fails, but on
    every implementation I've encountered it does. (That may be influenced
    by the fact that most of the implementations I've used are unixy, and I
    think POSIX *does* require the underlying system calls to set errno.)


    dave

    --
    Dave Vandervies dj3vande at eskimo dot com
    I've been curious about what 'lingua franca' actually meant for a while, and
    this seemed the perfect excuse to find out - and it appears to have worked.
    comp.lang.c will never cease to amaze me. --Richard Heathfield
     
    , May 30, 2008
    #2
    1. Advertising

  3. In article <>,
    gsa <> wrote:
    > I am new to C so please bear with my stupid questions. I am
    >trying to open a file to write, but the code complains that it is
    >unable to do so. How do I get C to print the reason it is failing?
    >Something like the $! function in perl.


    See the documentation on perror(). (Note: perror has some subtle
    limitations that can make it a better idea to use the lower-level
    equivilents... which you will likely find references to in the
    perror() documentation.)
    --
    "To all, to each! a fair good-night,
    And pleasing dreams, and slumbers light" -- Sir Walter Scott
     
    Walter Roberson, May 30, 2008
    #3
  4. gsa

    gsa Guest

    Thanks all! Did it with function error().
     
    gsa, May 30, 2008
    #4
  5. gsa

    gsa Guest

    I just stuck the error function call in the if block and it worked.

    if((fp = fopen(stretchesFile, "w")) == NULL) {
    error(1, errno, "could not open file %s", stretchesFile);
    exit(1);
    }

    Thanks again for your help!!
     
    gsa, May 30, 2008
    #5
  6. gsa

    Guest

    In article <>,
    gsa <> wrote:
    >I just stuck the error function call in the if block and it worked.
    >
    >if((fp = fopen(stretchesFile, "w")) == NULL) {
    > error(1, errno, "could not open file %s", stretchesFile);
    > exit(1);
    > }
    >
    >Thanks again for your help!!


    Note that error() is not portable; the man page on my system says:
    These functions and variables are GNU extensions, and should not be
    used in programs intended to be portable.
    So if you plan to use this program anywhere other than on Linux, you
    should probably use the portable building blocks (error() appears to be
    built on strerror(), exit(), and a few stdio functions, plus an
    extension to get the value of argv[0] somewhere outside of main())
    instead of the GNU convenience wrapper.
    (In your case, it may be acceptable to plan to write your own version
    of error() when you want to run somewhere other than Linux, since it
    gives you a one-line call that does a set of things that's not-quite-
    trivial to write yourself. But you should be aware of the
    nonportability and make sure that the benefits do indeed exceed the
    costs.)


    dave

    --
    Dave Vandervies dj3vande at eskimo dot com
    I've been curious about what 'lingua franca' actually meant for a while, and
    this seemed the perfect excuse to find out - and it appears to have worked.
    comp.lang.c will never cease to amaze me. --Richard Heathfield
     
    , May 30, 2008
    #6
  7. gsa

    pereges Guest

    I personally use fprintf. For eg:

    typedef struct xyz_struct
    {
    ..
    }*xyzptr;

    void foo()
    {
    xyzptr p;

    p = malloc(sizeof(*p));

    if(p == NULL)
    frpintf("Unable to allocate memory: %s %d %s", __FILE__,
    __LINE__,__func__);
    ..
    }



    I'm not sure if this is a good method though
     
    pereges, May 30, 2008
    #7
  8. "gsa" <> wrote in message
    news:...
    >I just stuck the error function call in the if block and it worked.
    >
    > if((fp = fopen(stretchesFile, "w")) == NULL) {
    > error(1, errno, "could not open file %s", stretchesFile);
    > exit(1);
    > }
    >
    > Thanks again for your help!!


    For my 2 cents worth exit(1) isn't portable. Try exit(EXIT_FAILURE) from
    stdlib.h. For me it has made the difference between a working and non
    working program.

    Bill
     
    Bill Cunningham, May 31, 2008
    #8
  9. gsa

    Richard Guest

    "Bill Cunningham" <> writes:

    > "gsa" <> wrote in message
    > news:...
    >>I just stuck the error function call in the if block and it worked.
    >>
    >> if((fp = fopen(stretchesFile, "w")) == NULL) {
    >> error(1, errno, "could not open file %s", stretchesFile);
    >> exit(1);
    >> }
    >>
    >> Thanks again for your help!!

    >
    > For my 2 cents worth exit(1) isn't portable. Try exit(EXIT_FAILURE) from
    > stdlib.h. For me it has made the difference between a working and non
    > working program.
    >
    > Bill


    I do not believe you. I would be interested in seeing this program that
    suddenly magically worked when you change the code you call exit with.
     
    Richard, May 31, 2008
    #9
  10. gsa

    santosh Guest

    Bill Cunningham wrote:

    >
    > "gsa" <> wrote in message
    >

    news:...
    >>I just stuck the error function call in the if block and it worked.
    >>
    >> if((fp = fopen(stretchesFile, "w")) == NULL) {
    >> error(1, errno, "could not open file %s", stretchesFile);
    >> exit(1);
    >> }
    >>
    >> Thanks again for your help!!

    >
    > For my 2 cents worth exit(1) isn't portable. Try
    > exit(EXIT_FAILURE) from
    > stdlib.h. For me it has made the difference between a working and non
    > working program.


    exit(1) didn't work? What's your system and what exactly happened, i.e.,
    what was the behaviour that made you conclude that exit(1) failed.
     
    santosh, May 31, 2008
    #10
  11. gsa

    Richard Guest

    santosh <> writes:

    > Bill Cunningham wrote:
    >
    >>
    >> "gsa" <> wrote in message
    >>

    > news:...
    >>>I just stuck the error function call in the if block and it worked.
    >>>
    >>> if((fp = fopen(stretchesFile, "w")) == NULL) {
    >>> error(1, errno, "could not open file %s", stretchesFile);
    >>> exit(1);
    >>> }
    >>>
    >>> Thanks again for your help!!

    >>
    >> For my 2 cents worth exit(1) isn't portable. Try
    >> exit(EXIT_FAILURE) from
    >> stdlib.h. For me it has made the difference between a working and non
    >> working program.

    >
    > exit(1) didn't work? What's your system and what exactly happened, i.e.,
    > what was the behaviour that made you conclude that exit(1) failed.


    He is trolling. I replied before realising who it was.
     
    Richard, May 31, 2008
    #11
  12. "Bill Cunningham" <> writes:
    > "gsa" <> wrote in message
    > news:...
    >>I just stuck the error function call in the if block and it worked.
    >>
    >> if((fp = fopen(stretchesFile, "w")) == NULL) {
    >> error(1, errno, "could not open file %s", stretchesFile);
    >> exit(1);
    >> }
    >>
    >> Thanks again for your help!!

    >
    > For my 2 cents worth exit(1) isn't portable. Try
    > exit(EXIT_FAILURE) from stdlib.h. For me it has made the difference
    > between a working and non working program.


    Really?

    You're absolutely right that exit(1) isn't portable, and
    exit(EXIT_FAILURE) is preferred.

    But it won't affect the behavior of the program itself until it
    terminates -- and on most systems you're likely to be using
    (including, I'm fairly sure, all variations of Unix and Windows),
    exit(1) and exit(EXIT_FAILURE) happen to behave the same way. (You're
    not using VMS, are you?)

    Perhaps you happened to make some other fix at the same time that you
    changed the exit() call.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 31, 2008
    #12
  13. CBFalconer <> writes:
    > santosh wrote:
    >> Bill Cunningham wrote:
    >>

    > ... snip ...
    >>
    >>> For my 2 cents worth exit(1) isn't portable. Try
    >>> exit(EXIT_FAILURE) from
    >>> stdlib.h. For me it has made the difference between a working
    >>> and non working program.

    >>
    >> exit(1) didn't work? What's your system and what exactly happened,
    >> i.e., what was the behaviour that made you conclude that exit(1)
    >> failed.

    >
    > "exit(1);" never is portable, and has absolutely no guarantees.
    > Bill is right here, the only guaranteed values for exit are 0,
    > EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.


    Bill is of course 100% correct that exit(1) is not portable. But
    that's not all he said. He also said that it "has made the difference
    between a working and non working program". I find that claim
    surprising (for reasons that happen to be beyond the scope of the C
    standard).

    Do you have reason to believe that it actually did make such a
    difference?

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, Jun 1, 2008
    #13
  14. gsa

    Guest

    On Jun 1, 3:06 am, CBFalconer <> wrote:
    > santosh wrote:
    > > Bill Cunningham wrote:

    >
    > ... snip ...
    >
    > >> For my 2 cents worth exit(1) isn't portable. Try
    > >> exit(EXIT_FAILURE) from
    > >> stdlib.h. For me it has made the difference between a working
    > >> and non working program.

    >
    > > exit(1) didn't work? What's your system and what exactly happened,
    > > i.e., what was the behaviour that made you conclude that exit(1)
    > > failed.

    >
    > "exit(1);" never is portable, and has absolutely no guarantees.
    > Bill is right here, the only guaranteed values for exit are 0,
    > EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.

    AFAIK exit(1) has guarantees about the behavior of the program. It
    doesn't guarantee a meaningful value to be returned.
     
    , Jun 1, 2008
    #14
  15. gsa

    santosh Guest

    CBFalconer wrote:

    > santosh wrote:
    >> Bill Cunningham wrote:
    >>

    > ... snip ...
    >>
    >>> For my 2 cents worth exit(1) isn't portable. Try
    >>> exit(EXIT_FAILURE) from
    >>> stdlib.h. For me it has made the difference between a working
    >>> and non working program.

    >>
    >> exit(1) didn't work? What's your system and what exactly happened,
    >> i.e., what was the behaviour that made you conclude that exit(1)
    >> failed.

    >
    > "exit(1);" never is portable, and has absolutely no guarantees.


    Of course. But I'm interested to hear the details of the implementation
    under which exit(1) resulted in a "non working program", as Bill
    claims.

    > Bill is right here, the only guaranteed values for exit are 0,
    > EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.


    It should be EXIT_SUCCESS, not EXIT_OK.
     
    santosh, Jun 1, 2008
    #15
  16. gsa

    Richard Guest

    writes:

    > On Jun 1, 3:06 am, CBFalconer <> wrote:
    >> santosh wrote:
    >> > Bill Cunningham wrote:

    >>
    >> ... snip ...
    >>
    >> >> For my 2 cents worth exit(1) isn't portable. Try
    >> >> exit(EXIT_FAILURE) from
    >> >> stdlib.h. For me it has made the difference between a working
    >> >> and non working program.

    >>
    >> > exit(1) didn't work? What's your system and what exactly happened,
    >> > i.e., what was the behaviour that made you conclude that exit(1)
    >> > failed.

    >>
    >> "exit(1);" never is portable, and has absolutely no guarantees.
    >> Bill is right here, the only guaranteed values for exit are 0,
    >> EXIT_OK, and EXT_FAILURE. The latter two require include stdlib.h.

    > AFAIK exit(1) has guarantees about the behavior of the program. It
    > doesn't guarantee a meaningful value to be returned.


    What do you mean AFAIK? What do you expect to go wrong with the program
    when exit is called? And talk in standard C in this case - I am not
    concerned about return codes to system calls for example.
     
    Richard, Jun 1, 2008
    #16
  17. gsa

    santosh Guest

    Eric Sosman wrote:

    > gsa wrote:
    >> Hi,
    >> I am new to C so please bear with my stupid questions. I am
    >> trying to open a file to write, but the code complains that it is
    >> unable to do so. How do I get C to print the reason it is failing?
    >> Something like the $! function in perl. Thanks a lot for all your
    >> help.

    >
    > FILE *stream = fopen(filename, mode);
    > if (stream == NULL) {
    > perror(filename);
    > ... whatever else ...
    > }
    >
    > This is not absolutely airtight, because fopen() is not
    > *required* to describe its reason for failing by storing a
    > value in `errno'. So there's a chance you'll get some
    > completely bogus "reason" for the failure, and that could
    > confuse the person reading the message. In my experience,
    > most C implementations *do* set `errno' when fopen() fails,
    > so I feel the benefit of displaying what `errno' says outweighs
    > the risk that what it says might be nonsense.
    >
    > Two warnings: First, display information from `errno'
    > only after you've determined that there's been a failure;
    > `errno' itself is not a failure-detection mechanism. Second,
    > don't call other functions between the point of failure and
    > the point when you call perror(), because they may change the
    > value of `errno' even on successful calls.


    Also a small additional point. You might want to set errno to zero just
    before a call to a library function. Since library functions are
    guaranteed to not store zero in errno, you can be sure that the value
    you are reading (and it's associated error message) has been set by the
    previous function call, and not some "left over" value.
     
    santosh, Jun 2, 2008
    #17
  18. gsa

    santosh Guest

    gsa wrote:

    > I just stuck the error function call in the if block and it worked.
    >
    > if((fp = fopen(stretchesFile, "w")) == NULL) {
    > error(1, errno, "could not open file %s", stretchesFile);
    > exit(1);
    > }
    >
    > Thanks again for your help!!


    There is no standard function called error. You are using an
    implementation specific extension which might not be available under
    the next compiler you try your code with.
     
    santosh, Jun 2, 2008
    #18
  19. gsa

    Baboon Guest

    santosh wrote:

    > Bill Cunningham wrote:
    >
    >>
    >> "gsa" <> wrote in message
    >>

    > news:...
    >>>I just stuck the error function call in the if block and it worked.
    >>>
    >>> if((fp = fopen(stretchesFile, "w")) == NULL) {
    >>> error(1, errno, "could not open file %s", stretchesFile);
    >>> exit(1);
    >>> }
    >>>
    >>> Thanks again for your help!!

    >>
    >> For my 2 cents worth exit(1) isn't portable. Try
    >> exit(EXIT_FAILURE) from
    >> stdlib.h. For me it has made the difference between a working and non
    >> working program.

    >
    > exit(1) didn't work? What's your system and what exactly happened, i.e.,
    > what was the behaviour that made you conclude that exit(1) failed.
    >


    On my Binford DS 6100, exit(), when passed these values,
    behaves as follows:

    EXIT_SUCCESS (0)
    return to host environment indicating success

    EXIT_FAILURE (42)
    return to host environment indicating failure

    EXIT_NOP (1)
    return to the function that called exit()

    [further documented exit codes omitted]

    Does that violate any standards?
     
    Baboon, Jun 4, 2008
    #19
  20. On 30 May, 19:04, pereges <> wrote:

    > I personally use fprintf [for error reporting]. For eg:


    <snip>

    > void foo()
    > {
    >   xyzptr p;
    >
    >   p = malloc(sizeof(*p));
    >
    >   if(p == NULL)
    >     frpintf("Unable to allocate memory: %s %d %s", __FILE__,
    > __LINE__,__func__);
    >   ..
    >
    > }
    >
    > I'm not sure if this is a good method though



    It's not a bad idea, though it might be a good idea to
    specify a file (stream) to write to


    frpintf(stderr, "Unable to allocate memory: %s %d %s", __FILE__,
    __LINE__,__func__);

    and note __func___ is only available with the latest standard
    (C99) which is still only patchily supported.


    --
    Nick Keighley
     
    Nick Keighley, Jun 5, 2008
    #20
    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. tshad
    Replies:
    0
    Views:
    314
    tshad
    Jan 25, 2005
  2. tshad
    Replies:
    2
    Views:
    472
    tshad
    Jan 27, 2005
  3. mikeorb
    Replies:
    3
    Views:
    722
    Bruce Barker
    Aug 29, 2005
  4. Daniel
    Replies:
    3
    Views:
    345
    Pascal J. Bourguignon
    May 15, 2009
  5. Kga Agk
    Replies:
    1
    Views:
    106
    Kga Agk
    Jun 19, 2009
Loading...

Share This Page