strtoul () vs. errno

Discussion in 'C Programming' started by Ivan Shmakov, May 4, 2012.

  1. Ivan Shmakov

    Ivan Shmakov Guest

    >>>>> Scott Lurndal <> writes:
    >>>>> Volker Birk <> writes:
    >>>>> Bill Cunningham <> wrote:


    [Cross-posting to news:comp.lang.c, for strtoul () is part of
    ISO C.]

    >>> errno = 0;


    >> You shouldn't set errno yourself. The behaviour is undefined.


    > Incorrect. There are a number of POSIX defined calls where you
    > _must_ clear errno prior to the call in order to detect that an error
    > occurred during the call (strtoul, for example).


    Curiously enough, I've always tested for failure with
    (*endptr == str) after the call. To my mind, it aligns better
    with the calling conventions of other functions, where one
    checks the return value for failure first, and checks errno for
    the cause if necessary afterwards.

    --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --
    If the subject sequence is empty or does not have the expected form,
    no conversion shall be performed; the value of str shall be stored
    in the object pointed to by endptr, provided that endptr is not a
    null pointer.
    --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --

    --
    FSF associate member #7257
     
    Ivan Shmakov, May 4, 2012
    #1
    1. Advertising

  2. Ivan Shmakov <> writes:

    >>>>>> Scott Lurndal <> writes:
    >>>>>> Volker Birk <> writes:
    >>>>>> Bill Cunningham <> wrote:

    >
    > [Cross-posting to news:comp.lang.c, for strtoul () is part of
    > ISO C.]
    >
    > >>> errno = 0;

    >
    > >> You shouldn't set errno yourself. The behaviour is undefined.

    >
    > > Incorrect. There are a number of POSIX defined calls where you
    > > _must_ clear errno prior to the call in order to detect that an error
    > > occurred during the call (strtoul, for example).

    >
    > Curiously enough, I've always tested for failure with
    > (*endptr == str) after the call. To my mind, it aligns better
    > with the calling conventions of other functions, where one
    > checks the return value for failure first, and checks errno for
    > the cause if necessary afterwards.
    >
    > --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --
    > If the subject sequence is empty or does not have the expected form,
    > no conversion shall be performed; the value of str shall be stored
    > in the object pointed to by endptr, provided that endptr is not a
    > null pointer.
    > --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --


    That misses the ERANGE case.

    --
    Måns Rullgård
     
    Måns Rullgård, May 4, 2012
    #2
    1. Advertising

  3. Ivan Shmakov

    James Kuyper Guest

    On 05/04/2012 06:50 AM, Ivan Shmakov wrote:
    >>>>>> Scott Lurndal <> writes:
    >>>>>> Volker Birk <> writes:
    >>>>>> Bill Cunningham <> wrote:

    >
    > [Cross-posting to news:comp.lang.c, for strtoul () is part of
    > ISO C.]
    >
    > >>> errno = 0;

    >
    > >> You shouldn't set errno yourself. The behaviour is undefined.


    The C standard says nothing of the kind. In fact, footnote 122 in
    n1570.pdf says: "Thus, a program that uses errno for error checking
    should set it to zero before a library function call," The standard
    library functions are restricted to setting errno to positive values,
    precisely so that negative values may be used by any user code to
    indicate additional error conditions.

    > > Incorrect. There are a number of POSIX defined calls where you
    > > _must_ clear errno prior to the call in order to detect that an error
    > > occurred during the call (strtoul, for example).

    >
    > Curiously enough, I've always tested for failure with
    > (*endptr == str) after the call. To my mind, it aligns better
    > with the calling conventions of other functions, where one
    > checks the return value for failure first, and checks errno for
    > the cause if necessary afterwards.
    >
    > --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --
    > If the subject sequence is empty or does not have the expected form,
    > no conversion shall be performed; the value of str shall be stored
    > in the object pointed to by endptr, provided that endptr is not a
    > null pointer.
    > --cut: http://pubs.opengroup.org/onlinepubs/9699919799/functions/strtoul.html --


    However, note that those are not the only possible error conditions.
    Even if the subject sequence is not empty, and does have the expected
    form, "If the correct value is outside the range of representable
    values, ... ULONG_MAX ... is returned ... and the value of the macro
    ERANGE is stored in errno." (C2011 7.22.1.4p8).
    --
    James Kuyper
     
    James Kuyper, May 4, 2012
    #3
  4. Scott Lurndal wrote:
    > Ivan Shmakov <> writes:
    >>>>>>> Scott Lurndal <> writes:
    >>>>>>> Volker Birk <> writes:
    >>>>>>> Bill Cunningham <> wrote:

    >>
    >> [Cross-posting to news:comp.lang.c, for strtoul () is part of
    >> ISO C.]
    >>
    >>>>> errno = 0;

    >>
    >>>> You shouldn't set errno yourself. The behaviour is undefined.

    >>
    >>> Incorrect. There are a number of POSIX defined calls where you
    >>> _must_ clear errno prior to the call in order to detect that an
    >>> error occurred during the call (strtoul, for example).

    >>
    >> Curiously enough, I've always tested for failure with
    >> (*endptr == str) after the call. To my mind, it aligns better
    >> with the calling conventions of other functions, where one
    >> checks the return value for failure first, and checks errno for
    >> the cause if necessary afterwards.

    >
    > I also use code similar to:
    >
    > bus = strtoull(argv[2], &cp, 0);
    > if ((cp == argv[2])
    > || (*cp != '\0')
    > || (bus > c_pcie_ecam::NUM_BUSES)) {
    > lp->log("Bus number must be less than %zu\n",
    > c_pcie_ecam::NUM_BUSES);


    Is that :: above C++'s scoping operator?

    > return false;
    > }
    >
    > This does catch ERANGE errors, since the returned ULLONG_MAX value
    > will be larger than the constraint.
    >
    > scott
     
    Bill Cunningham, May 4, 2012
    #4
    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. Markus Elfring

    conversion: errno => exception

    Markus Elfring, Nov 8, 2004, in forum: C++
    Replies:
    13
    Views:
    3,448
    Markus Elfring
    Jan 5, 2005
  2. Return Value of atoi and strtoul

    , Apr 16, 2007, in forum: C Programming
    Replies:
    4
    Views:
    913
    Flash Gordon
    Apr 17, 2007
  3. viza

    &errno, sizeof errno

    viza, Sep 12, 2008, in forum: C Programming
    Replies:
    20
    Views:
    1,056
    Tim Rentsch
    Sep 14, 2008
  4. Glenn Linderman

    errno 22 instead of errno 2

    Glenn Linderman, Jan 28, 2009, in forum: Python
    Replies:
    0
    Views:
    381
    Glenn Linderman
    Jan 28, 2009
  5. arnuld

    strtoul() behavior

    arnuld, Jan 5, 2011, in forum: C Programming
    Replies:
    39
    Views:
    3,238
    arnuld
    Jan 12, 2011
Loading...

Share This Page