This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Portability of idiom


> To me the meaning is dead clear. [...]

I do see that Plauger agrees with your assessment in his commentary on
proper portable application-level usage of errno.  I also see that the
standard text I quoted was unchanged from C89.  I am sorry I didn't
try to read more history before questioning the idiom.

> [...] Sometimes we may have to work around a buggy libc, but let's
> not pretend it's OK.

To pretend it's OK was never my intention.  This is exactly why I
posted the situation with as much context as possible.

> Maybe we should abort if we get a disallowed errno value, unless
> it's one that configure has identified as a known bug on the target.

Under the assumption that there are no buggy libc, the code as written
was 100% perfect since there is only one documented errno setting
strto* can make.  Under that same assumption, the code as I patched it
is still 100% perfect.  The only thing I can agree to is that I have
set the tradeoff for working with a buggy libc the other way.  If
there was a buggy libc that meant to signal an error via errno being
set to nonzero and non-ERANGE, then I just helped a port I care about
at their expense (doing that was not my intention).

You are asking for the code to be made even more robust than it was
originally written or as a tweaked the detection tradeoff.  This is
not a bad thing.  You are asking for a fast binary decision:

  if (errno)
    handle_error ();
  else
    use_results ();

to be turned into a three-way with more complex checks (pseudo):

  if (errno is in some set)
    handle_error ();
  else if (errno is in another set)
    abort ();
  else
    use_results ();

Or, written as somewhat optimized so only buggy ports pay the bulk of
the overhead:

#if _GLIBCPP_FUNCTION_HAS_GRATUITOUS_ERRNO
  // Heaven help us in general with multiple gratiutious values
  if (errno == _GLIBCPP_FUNCTION_HAS_GRATUITOUS_ERRNO)
    errno = 0;
#endif
  if (!errno)
    use_results ();
  else if (errno == ERANGE)
    handle_error ();
  else
    abort ();

Note: FUNCTION in _GLIBCPP_FUNCTION_HAS_GRATUITOUS_ERRNO is a
placeholder, normal configure conventions hold that it is the upcased
name of the buggy function.  I do not actually know if normal
conventions allow me to set _GLIBCPP_FUNCTION_HAS_GRATUITOUS_ERRNO
to the value of the gratiutious errno.

As people find aborts in the test cases (which hopefully cover all
corner cases), they will have to add configure tests that correctly
find the buggy libc behavior and set _GLIBCPP_FUNCTION_HAS_GRATUITOUS_ERRNO
appropriately.

Is that, more or less, what you want to see?

Regards,
Loren


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]