Re: [v3 PATCH] Fix Cygwin bootstrap failure: ECANCELED in system_error

[bkoz <benjamin dot kosnik at gmail dot com>]

> The following patch fixes the current libstdc++ bootstrap failure on
> i686-pc-cygwin.  The issue is that the new system_error header file
> unconditionally uses the value ECANCELED.  Alas not all almost POSIX systems
> provide this value in sys/errno.h.
>
> The fix is similar to Ben Kosnik's previous fix for FreeBSD, and my previous
> fix for Darwin, to add a suitable configure check, and then guard the usage
> of ECANCEL and std::operation_canceled by _GLIBCXX_HAVE_ECANCELED.
>
> The following patch has been tested on both i686-pc-cygwin and
> x86_64-unknown-linux-gnu with a full "make bootstrap", where it allows the
> former to complete without problems.  I then ran a top-level "make -k check"
> on the later to confirm that there are no new libstdc++ testsuite failures.
>
> Ok for mainline?

Yes.

> I'm unsure as to the standard wording for system_error, but I was wondering
> if rather than removing the symbols operation_canceled and bad_message from
> the std namespace on affected platforms, we retain them but assign them a
> unique value.  This then preserves source code compatability of C++ user
> code, it's just that the OS won't ever generate an errno value of
> operation_canceled.  I was giving some thought to how one could assign these
> unique values when I discovered that E-values aren't required to be unique.
> Several OSes #define one value to another.  i.e. #define EAGAIN EWOULDBLOCK.
> If this is permitted, it means that these constants can't be used in switch
> statements, because they are not guaranteed unique.  This would simplify
> things to the point that on affected platforms we could simply have
> "operation_canceled = 0", "bad_message = 0" etc...  Thoughts?

The standard wording for <system_error> is in a bit of flux. I'm
hoping the dust settles post-next meeting.

I too would rather have a system error with constants that are
actually unique, for the reasons you mention. It seems foolish to me
to reproduce this wart from the C side in a C++ interface.

Certainly, the current approach of libstdc++ (commenting out bits that
don't exist on the native platform) is straight out wrong.

However, it's expedient and it lets us figure out the lay of the land
WRT these defines across a large number of os'es. That's been useful.

-benjamin