Definition of perror() ?

Discussion in 'C Programming' started by Disc Magnet, Jan 3, 2011.

  1. Disc Magnet

    Disc Magnet Guest

    Is perror(s) just a macro to fprintf(stderr, "%s: %s\n", s,
    strerror(errno)) ?
    Disc Magnet, Jan 3, 2011
    #1
    1. Advertising

  2. Disc Magnet

    Ben Pfaff Guest

    Disc Magnet <> writes:

    > Is perror(s) just a macro to fprintf(stderr, "%s: %s\n", s,
    > strerror(errno)) ?


    Literally? No. But the effects are similar in the common case.
    --
    Ben Pfaff
    http://benpfaff.org
    Ben Pfaff, Jan 3, 2011
    #2
    1. Advertising

  3. Disc Magnet <> writes:
    > Is perror(s) just a macro to fprintf(stderr, "%s: %s\n", s,
    > strerror(errno)) ?


    perror() is a standard library function. For the actual definition,
    grab a copy of
    <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
    (that's the latest draft of the C standard) and read section 7.19.10.4.

    Like any standard library function, it may additionally be defined as
    a macro.

    For a couple of reasons, the definition you present would not be
    legal; first, the reference to s needs to be parenthesized, and
    second, the behavior is different if s is a null pointer or points
    to a null character.

    I'm not sure how I'd define perror() as a macro that doesn't
    potentially evaluate its argument more than once. And there's
    probably not much reason to bother doing so; a call to perror()
    isn't likely to be a performance bottleneck.

    --
    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, Jan 3, 2011
    #3
  4. Disc Magnet

    Eric Sosman Guest

    On 1/3/2011 5:45 PM, Keith Thompson wrote:
    > Disc Magnet<> writes:
    >> Is perror(s) just a macro to fprintf(stderr, "%s: %s\n", s,
    >> strerror(errno)) ?

    >
    > perror() is a standard library function. For the actual definition,
    > grab a copy of
    > <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>
    > (that's the latest draft of the C standard) and read section 7.19.10.4.
    >
    > Like any standard library function, it may additionally be defined as
    > a macro.
    >
    > For a couple of reasons, the definition you present would not be
    > legal; first, the reference to s needs to be parenthesized, and
    > second, the behavior is different if s is a null pointer or points
    > to a null character.


    Another reason it wouldn't be legal is that you can use perror()
    in a module that #include's <stdio.h> but omits <string.h>, which is
    where strerror() is declared.

    And there's yet another reason, this one truly nit-picky: "The
    implementation shall behave as if no library function calls the
    strerror function." If strerror() uses a static internal buffer to
    hold the message string, and overwrites the buffer at each call, the
    macro-ized perror() would cause a forbidden overwrite. That is, in

    const char *message = strerror(EDOM);
    strcpy (big_enough_array, message);
    errno = ERANGE;
    perror("This is a range error");
    assert (strcmp(message, big_enough_array) == 0);

    .... the assertion must not fail, as it (almost certainly) would if
    perror() called strerror() and the latter overwrote its buffer.

    > I'm not sure how I'd define perror() as a macro that doesn't
    > potentially evaluate its argument more than once. And there's
    > probably not much reason to bother doing so; a call to perror()
    > isn't likely to be a performance bottleneck.


    Indeed. A program whose performance is limited by the speed at
    which it can report its own errors most likely has problems other
    than performance. ;-)

    --
    Eric Sosman
    lid
    Eric Sosman, Jan 3, 2011
    #4
  5. Disc Magnet

    Eric Sosman Guest

    On 1/4/2011 1:02 PM, Kenneth Brody wrote:
    > On 1/3/2011 6:30 PM, Eric Sosman wrote:
    >> On 1/3/2011 5:45 PM, Keith Thompson wrote:

    > [...]
    >>> I'm not sure how I'd define perror() as a macro that doesn't
    >>> potentially evaluate its argument more than once. And there's
    >>> probably not much reason to bother doing so; a call to perror()
    >>> isn't likely to be a performance bottleneck.

    >>
    >> Indeed. A program whose performance is limited by the speed at
    >> which it can report its own errors most likely has problems other
    >> than performance. ;-)

    >
    > Well, in college, we had a FORTRAN compiler which was very efficient at
    > generating non-optimized code. (The point being, why waste CPU cycles
    > optimizing a program which is likely to not compile the first N times,
    > and which would likely be run only a single time once it actually did
    > compile.) It would generate extremely verbose, and extremely numerous,
    > error messages.


    So it spat out lots of messages about *your* errors, not about
    "its own errors," right? :)

    --
    Eric Sosman
    lid
    Eric Sosman, Jan 4, 2011
    #5
  6. Disc Magnet

    Guest

    On Jan 4, 12:02 pm, Kenneth Brody <> wrote:
    > On 1/3/2011 6:30 PM, Eric Sosman wrote:
    >
    > > On 1/3/2011 5:45 PM, Keith Thompson wrote:

    > [...]
    > >> I'm not sure how I'd define perror() as a macro that doesn't
    > >> potentially evaluate its argument more than once. And there's
    > >> probably not much reason to bother doing so; a call to perror()
    > >> isn't likely to be a performance bottleneck.

    >
    > > Indeed. A program whose performance is limited by the speed at
    > > which it can report its own errors most likely has problems other
    > > than performance. ;-)

    >
    > Well, in college, we had a FORTRAN compiler which was very efficient at
    > generating non-optimized code.  (The point being, why waste CPU cycles
    > optimizing a program which is likely to not compile the first N times, and
    > which would likely be run only a single time once it actually did compile..)
    >   It would generate extremely verbose, and extremely numerous, error messages.



    Good old WATFOR and WATFIV... Typically these student jobs would be
    compile-link-and-go - the executable would never even get written to
    disk (after the linker finished, it would just be run from memory).
    So even if the student wanted to run the program more than once, it
    would be recompiled, since it wouldn't have been saved anyway. And of
    course, typical student problems were pretty small anyway, so not only
    was the program only run once, it would only process a dataset with
    (at most) a few hundred entries.
    , Jan 4, 2011
    #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. Replies:
    0
    Views:
    769
  2. L. Westmeier

    When to use "perror" and "fprintf"

    L. Westmeier, May 4, 2004, in forum: C Programming
    Replies:
    6
    Views:
    733
    OSHIMA
    May 13, 2004
  3. Martin
    Replies:
    7
    Views:
    690
    Chris Torek
    Dec 9, 2004
  4. Clunixchit

    perror question

    Clunixchit, Jun 19, 2005, in forum: C Programming
    Replies:
    1
    Views:
    333
    SM Ryan
    Jun 19, 2005
  5. puzzlecracker

    cout and perror

    puzzlecracker, Oct 22, 2005, in forum: C++
    Replies:
    3
    Views:
    340
    Branimir Maksimovic
    Oct 23, 2005
Loading...

Share This Page