Re: sanitize_read: map errno=EPIPE to errno=0

From: Sertonix <sertonix_at_posteo.net>
Date: Tue, 30 Jun 2026 16:26:10 +0000

On Tue Jun 30, 2026 at 5:38 PM CEST, Peter Pentchev wrote:
> On Tue, Jun 30, 2026 at 01:29:11PM +0000, Sertonix wrote:
>> Hi,
>>
>> reading some skalibs documentation and was wonder why sanitize_read does
>> not remap EPIPE to a different errno, avoid any possibility of state
>> confusion? Since "everything" can be a fd, I have seen too many unexpected
>> errno set by read/write that I would expect EPIPE to be possible as well.
>
> changing all the current checks for
> errno == EPIPE to checks for sanitize_read() returning 0

I didn't mean changing the return value, only the value of errno after
sanitize_read when errno was EPIPE prior to the sanitize_read call. That
would allow unsanitize_read to map it back to (errno = EPIPE, -1) instead
of incorrectly mapping it to (errno = 0, 0). Something like this:

diff --git a/src/libstddjb/sanitize_read.c b/src/libstddjb/sanitize_read.c
index a38f538..32702f0 100644
--- a/src/libstddjb/sanitize_read.c
+++ b/src/libstddjb/sanitize_read.c
_at__at_ -6,6 +6,6 _at__at_
 
 ssize_t sanitize_read (ssize_t r)
 {
- return r == -1 ? error_isagain(errno) ? (errno = 0, 0) : -1 :
+ return r == -1 ? error_isagain(errno) ? (errno = 0, 0) : errno == EPIPE ? (errno = 0, -1) : -1 :
          !r ? (errno = EPIPE, -1) : r ;
 }
diff --git a/src/libstddjb/unsanitize_read.c b/src/libstddjb/unsanitize_read.c
index 585e103..3ff25fb 100644
--- a/src/libstddjb/unsanitize_read.c
+++ b/src/libstddjb/unsanitize_read.c
_at__at_ -6,6 +6,6 _at__at_
 
 ssize_t unsanitize_read (ssize_t r)
 {
- return r == -1 ? errno == EPIPE ? (errno = 0, 0) : -1 :
+ return r == -1 ? errno == EPIPE ? (errno = 0, 0) : errno == 0 ? (errno = EPIPE, -1) : -1 :
          !r ? (errno = EWOULDBLOCK, -1) : r ;
 }

Or, when not being concerned about printing confusing error message
EPIPE could be mapped to EAGAIN. Then unsanitize_read would be able to
restore information even when read resulted in (errno = 0, -1).
Received on Tue Jun 30 2026 - 18:26:10 CEST

This archive was generated by hypermail 2.4.0 : Tue Jun 30 2026 - 18:26:44 CEST