errno.h: ESTRPIPE

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

errno.h: ESTRPIPE

Yaakov (Cygwin/X)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Corresponding patch just sent to newlib@.

2009-03-11  Yaakov Selkowitz <[hidden email]>

        * errno.cc (_sys_errlist): Add ESTRPIPE.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkm4ofgACgkQpiWmPGlmQSMrMACeJvUcrUQDnIrEVoiV58hruydi
Wb4AnRfbMgIVXEuH5qyvsrARXfJfWY7t
=4jCZ
-----END PGP SIGNATURE-----

Index: cygwin/errno.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/errno.cc,v
retrieving revision 1.70
diff -u -r1.70 errno.cc
--- cygwin/errno.cc 16 Jan 2009 12:17:27 -0000 1.70
+++ cygwin/errno.cc 12 Mar 2009 05:42:24 -0000
@@ -287,7 +287,8 @@
 /* EOVERFLOW 139 */  "Value too large for defined data type",
 /* ECANCELED 140 */  "Operation canceled",
 /* ENOTRECOVERABLE 141 */ "State not recoverable",
-/* EOWNERDEAD 142 */  "Previous owner died"
+/* EOWNERDEAD 142 */  "Previous owner died",
+/* ESTRPIPE 143 */  "Streams pipe error"
 };
 
 int NO_COPY_INIT _sys_nerr = sizeof (_sys_errlist) / sizeof (_sys_errlist[0]);
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Corinna Vinschen-2
On Mar 12 00:47, Yaakov S wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corresponding patch just sent to newlib@.
>
> 2009-03-11  Yaakov Selkowitz <[hidden email]>
>
> * errno.cc (_sys_errlist): Add ESTRPIPE.

Same question as asked by Ralf on the newlib list.

What exactly is this patch fixing?  Ok, we get a new error code, but
what for?  It's not generated from within Cygwin, so...?


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Eric Blake-2
> > 2009-03-11  Yaakov Selkowitz <[hidden email]>
> >
> > * errno.cc (_sys_errlist): Add ESTRPIPE.
>
> Same question as asked by Ralf on the newlib list.
>
> What exactly is this patch fixing?  Ok, we get a new error code, but
> what for?  It's not generated from within Cygwin, so...?

And it's not standardized, which means portable code shouldn't use it.

--
Eric Blake
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Yaakov (Cygwin/X)
In reply to this post by Corinna Vinschen-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Corinna Vinschen wrote:
> What exactly is this patch fixing?  Ok, we get a new error code, but
> what for?  It's not generated from within Cygwin, so...?

I came across a few packages that used it.  This gets us just a little
more compatible with Linux's errno.

Eric Blake wrote:
> And it's not standardized, which means portable code shouldn't use it.

That may be true, but I didn't write this code, and as I am sure you
already know, not everyone thinks about writing portable code.


Yaakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkm5isQACgkQpiWmPGlmQSP76gCgoZW9aAXA6NEstR7EjFfH/ZQl
yeIAoKX+E66iUrkYBHPbgyzf+47CEmSI
=05er
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Corinna Vinschen-2
On Mar 12 17:20, Yaakov S wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Corinna Vinschen wrote:
> > What exactly is this patch fixing?  Ok, we get a new error code, but
> > what for?  It's not generated from within Cygwin, so...?
>
> I came across a few packages that used it.  This gets us just a little
> more compatible with Linux's errno.

ESTRPIPE is returned by the Linux kernel in only one case:  If you try
to read from or write to a PCM sound device which is in suspended state.
This is very Linux device specific and this never occurs on Cygwin.
What about just defining this error code to some arbitrary value like

  #ifdef __CYGWIN__
  #define ESTRPIPE 9999
  #endif


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Warren Young
Corinna Vinschen wrote:
> This is very Linux device specific and this never occurs on Cygwin.
> What about just defining this error code to some arbitrary value like
>
>   #ifdef __CYGWIN__
>   #define ESTRPIPE 9999
>   #endif

I like it.  If there are any other errno constants supported by Linux
but not Cygwin, you could also define them with the same value.  It
would effectively be the "this never happens" value.
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Christopher Faylor-8
On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:

> Corinna Vinschen wrote:
>> This is very Linux device specific and this never occurs on Cygwin.
>> What about just defining this error code to some arbitrary value like
>>   #ifdef __CYGWIN__
>>   #define ESTRPIPE 9999
>>   #endif
>
> I like it.  If there are any other errno constants supported by Linux but
> not Cygwin, you could also define them with the same value.  It would
> effectively be the "this never happens" value.

I'm not sure that you got this but I think Corinna was suggesting that
this should be defined in the code in question rather than in Cygwin
itself.

I don't have a problem defining unique errnos that currently never
happen if it makes Cygwin more compatible with Linux.  I just think that
the value should be marked as

/* Linux compatibility: this currently can never happen */

Yaakov's intent was to reduce the amount of special casing required when
porting to Cygwin to remove the need to do #ifdef __CYGWIN__'s.  I think
he knows that he could have ifdef'ed this since I suspect that he's had
to do that many times in the past.

Defining a unique value means that, if we do decide at some point to add
functionality which utilizes that errno the will be no need to recompile
the application.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Warren Young
Christopher Faylor wrote:
> Defining a unique value means that, if we do decide at some point to add
> functionality which utilizes that errno the will be no need to recompile
> the application.

If you think Cygwin might at some point learn to send certain errnos,
they should use low values, as the standard ones do.  The point of using
9999 is to say "we'll never need this one," perhaps because it just
doesn't make sense for Cygwin.

I'd be surprised if there were actually errnos used by other *ixes that
Cygwin currently doesn't use, which are also not understood well enough
such that you can't predict whether Cygwin will ever need them for more
than compatibility.  Obviously the future is wide open and holds endless
surprises, but isn't Cygwin mature enough by now that its wish list is
mostly populated by obvious things?  Is there really a lot of stuff
coming in these days where you say, "didn't see that coming!"?
Reply | Threaded
Open this post in threaded view
|

RE: errno.h: ESTRPIPE

Peter Ekberg
In reply to this post by Warren Young
Warren Young skrev:

> Corinna Vinschen wrote:
> > This is very Linux device specific and this never occurs on Cygwin.
> > What about just defining this error code to some arbitrary
> value like
> >
> >   #ifdef __CYGWIN__
> >   #define ESTRPIPE 9999
> >   #endif
>
> I like it.  If there are any other errno constants supported by Linux
> but not Cygwin, you could also define them with the same value.  It
> would effectively be the "this never happens" value.

That a bad suggestion.

Consider code like this:

switch (errno) {
case -ESTRPIPE:
        capers();
        break;
case -EFOOBAR:
        cucumber();
        break;
}

If both ESTRPIPE and EFOOBAR are defined to 9999 that doesn't work too
well, and you end up having cygwin specific patches in any case.

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Corinna Vinschen-2
In reply to this post by Christopher Faylor-8
On Mar 13 10:50, Christopher Faylor wrote:

> On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:
> > Corinna Vinschen wrote:
> >> This is very Linux device specific and this never occurs on Cygwin.
> >> What about just defining this error code to some arbitrary value like
> >>   #ifdef __CYGWIN__
> >>   #define ESTRPIPE 9999
> >>   #endif
> >
> > I like it.  If there are any other errno constants supported by Linux but
> > not Cygwin, you could also define them with the same value.  It would
> > effectively be the "this never happens" value.
>
> I'm not sure that you got this but I think Corinna was suggesting that
> this should be defined in the code in question rather than in Cygwin
> itself.

Right.

> I don't have a problem defining unique errnos that currently never
> happen if it makes Cygwin more compatible with Linux.  I just think that
> the value should be marked as
>
> /* Linux compatibility: this currently can never happen */

Hmm, this doesn't make much sense in the newlib errno.h.  We already
have a couple of errnos which are not generated by Cygwin without such
a comment.

> Yaakov's intent was to reduce the amount of special casing required when
> porting to Cygwin to remove the need to do #ifdef __CYGWIN__'s.  I think
> he knows that he could have ifdef'ed this since I suspect that he's had
> to do that many times in the past.
>
> Defining a unique value means that, if we do decide at some point to add
> functionality which utilizes that errno the will be no need to recompile
> the application.

That's quite a good argument.  If you both think it's a good idea to
define this new errno, I'm fine with it, too.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Warren Young
In reply to this post by Peter Ekberg
Peter Rosin wrote:

> Consider code like this:
>
> switch (errno) {
> case -ESTRPIPE:
> capers();
> break;
> case -EFOOBAR:
> cucumber();
> break;
> }

The core assumption is that neither can happen.  Not now, not ever.

If that's true, the worst you can say against it is that gcc will bitch
about the duplicate switch case.  If it's not true, that kicks the legs
out from under the recommendation, so of course it shouldn't be done
that way.

It would also be fine with me if the first "can't happen" value were
9999, then the next 9998, etc.  I do like starting below 10000, as an
old Winsock hand.  Yes, I know, errno and WSAGetLastError() don't
overlap, but somehow it appeals to me to behave as if they could.
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Christopher Faylor-8
In reply to this post by Corinna Vinschen-2
On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote:

>On Mar 13 10:50, Christopher Faylor wrote:
>> On Fri, Mar 13, 2009 at 06:10:48AM -0600, Warren Young wrote:
>> > Corinna Vinschen wrote:
>> >> This is very Linux device specific and this never occurs on Cygwin.
>> >> What about just defining this error code to some arbitrary value like
>> >>   #ifdef __CYGWIN__
>> >>   #define ESTRPIPE 9999
>> >>   #endif
>> >
>> > I like it.  If there are any other errno constants supported by Linux but
>> > not Cygwin, you could also define them with the same value.  It would
>> > effectively be the "this never happens" value.
>>
>> I'm not sure that you got this but I think Corinna was suggesting that
>> this should be defined in the code in question rather than in Cygwin
>> itself.
>
>Right.
>
>> I don't have a problem defining unique errnos that currently never
>> happen if it makes Cygwin more compatible with Linux.  I just think that
>> the value should be marked as
>>
>> /* Linux compatibility: this currently can never happen */
>
>Hmm, this doesn't make much sense in the newlib errno.h.  We already
>have a couple of errnos which are not generated by Cygwin without such
>a comment.

I was just trying optimistically to avoid the mailing list email
wondering why the errno wasn't being generated.

>>Yaakov's intent was to reduce the amount of special casing required
>>when porting to Cygwin to remove the need to do #ifdef __CYGWIN__'s.  I
>>think he knows that he could have ifdef'ed this since I suspect that
>>he's had to do that many times in the past.
>>
>>Defining a unique value means that, if we do decide at some point to
>>add functionality which utilizes that errno there will be no need to
>>recompile the application.
>
>That's quite a good argument.  If you both think it's a good idea to
>define this new errno, I'm fine with it, too.

I was wondering if we should add a conditionalized "#include
<cygwin/errno.h>" to newlib's errno.h.  Then we could add things without
littering the file with #ifdef CYGWIN's.

cgf
Reply | Threaded
Open this post in threaded view
|

RE: errno.h: ESTRPIPE

Peter Ekberg
In reply to this post by Warren Young
Warren Young skrev:

> Peter Rosin wrote:
> > Consider code like this:
> >
> > switch (errno) {
> > case -ESTRPIPE:
> > capers();
> > break;
> > case -EFOOBAR:
> > cucumber();
> > break;
> > }
>
> The core assumption is that neither can happen.  Not now, not ever.
>
> If that's true, the worst you can say against it is that gcc
> will bitch
> about the duplicate switch case.  If it's not true, that
> kicks the legs
> out from under the recommendation, so of course it shouldn't be done
> that way.

Your core assumption doesn't matter. The worst I can say against it is
indeed that gcc will bitch about it, that was my whole point. gcc will
bitch about the above code regardless of the values cygwin will
assign to errno, as it's a compile time problem.

I should stress here that "gcc bitching" is in this case generating an
error and not finishing building whatever is being built.

Adding comptibility defines to help porting code should help porting,
and not require patching the package, that would just be silly.

> It would also be fine with me if the first "can't happen" value were
> 9999, then the next 9998, etc.  I do like starting below 10000, as an
> old Winsock hand.  Yes, I know, errno and WSAGetLastError() don't
> overlap, but somehow it appeals to me to behave as if they could.

But that was not what I protested against. I don't care what numbers
are selected as long as they are unique.

Cheers,
Peter
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Corinna Vinschen-2
In reply to this post by Christopher Faylor-8
On Mar 13 17:47, Christopher Faylor wrote:

> On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote:
> >On Mar 13 10:50, Christopher Faylor wrote:
> >>Defining a unique value means that, if we do decide at some point to
> >>add functionality which utilizes that errno there will be no need to
> >>recompile the application.
> >
> >That's quite a good argument.  If you both think it's a good idea to
> >define this new errno, I'm fine with it, too.
>
> I was wondering if we should add a conditionalized "#include
> <cygwin/errno.h>" to newlib's errno.h.  Then we could add things without
> littering the file with #ifdef CYGWIN's.

Actually I was going to propose the same idea yesterday when I wrote my
reply.  But then it occured to me that, *if* we add our own errno.h, we
would have to make sure that we start with our own errnos at a value way
above EOWNERDEAD so that we don't get an errno clash when new errnos are
added to newlib.  But in this case we raise the size of _sys_errlist
with empty slots for no good reason.  And the worst case, newlib adds an
errno with another value than what's defined in cygwin/errno.h.

So, if we add this errno, just stick it to newlib's sys/errno.h as in
Yaakovs original patch.

If that's ok with you I'll apply Yaakov's patch on Monday.


Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Christopher Faylor-8
On Sat, Mar 14, 2009 at 10:25:59AM +0100, Corinna Vinschen wrote:

>On Mar 13 17:47, Christopher Faylor wrote:
>>On Fri, Mar 13, 2009 at 09:59:49PM +0100, Corinna Vinschen wrote:
>>>On Mar 13 10:50, Christopher Faylor wrote:
>>>>Defining a unique value means that, if we do decide at some point to
>>>>add functionality which utilizes that errno there will be no need to
>>>>recompile the application.
>>>
>>>That's quite a good argument.  If you both think it's a good idea to
>>>define this new errno, I'm fine with it, too.
>>
>>I was wondering if we should add a conditionalized "#include
>><cygwin/errno.h>" to newlib's errno.h.  Then we could add things
>>without littering the file with #ifdef CYGWIN's.
>
>Actually I was going to propose the same idea yesterday when I wrote my
>reply.  But then it occured to me that, *if* we add our own errno.h, we
>would have to make sure that we start with our own errnos at a value
>way above EOWNERDEAD so that we don't get an errno clash when new
>errnos are added to newlib.  But in this case we raise the size of
>_sys_errlist with empty slots for no good reason.  And the worst case,
>newlib adds an errno with another value than what's defined in
>cygwin/errno.h.

Ah, right.  I think I go through the cycle of thinking this is a good
idea and then realizing it won't work every year or so.  I guess I
needed you to complete the cycle.

>So, if we add this errno, just stick it to newlib's sys/errno.h as in
>Yaakovs original patch.
>
>If that's ok with you I'll apply Yaakov's patch on Monday.

No objections.

cgf
Reply | Threaded
Open this post in threaded view
|

Re: errno.h: ESTRPIPE

Corinna Vinschen-2
In reply to this post by Yaakov (Cygwin/X)
On Mar 12 00:47, Yaakov S wrote:
> 2009-03-11  Yaakov Selkowitz <[hidden email]>
>
> * errno.cc (_sys_errlist): Add ESTRPIPE.

Applied.

Thanks,
Corinna

--
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat