Skip Menu |

This queue is for tickets about the ExtUtils-Install CPAN distribution.

Report information
The Basics
Id: 91583
Status: open
Priority: 0/
Queue: ExtUtils-Install
People
Owner: Nobody in particular
Requestors: victor [...] vsespb.ru
Cc:
AdminCc:
Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)

History Show all quoted text
  Sun Dec 22 17:35:24 2013 victor [...] vsespb.ru - Ticket created
Subject: syswrite return values in not checked in run_filter
while (my $len = sysread(SRC, $buf, $sz)) { syswrite(CMD, $buf, $len); } in this code syswrite is writing to pipe, thus can return undef + $!{EINTR} or something less than $sz bytes. just found one old report http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/62216 where person sees files truncated after this.
  Tue Nov 18 20:49:30 2014 jkeenan [...] cpan.org - Correspondence added
On Sun Dec 22 17:35:24 2013, vsespb wrote: Show quoted text
> while (my $len = sysread(SRC, $buf, $sz)) { > syswrite(CMD, $buf, $len); > } > > in this code syswrite is writing to pipe, thus can return undef + > $!{EINTR} or something less than $sz bytes. >
The documentation for 'syswrite' (perl-5.20.1) says that it: ##### Returns the number of bytes actually written, or "undef" if there was an error (in this case the errno variable $! is also set). If the LENGTH is greater than the data available in the SCALAR after the OFFSET, only as much data as is available will be written. ##### Now, suppose that we checked the return value of 'syswrite' at the location cited. What would be the appropriate action if it were 'undef'? Thank you very much. Jim Keenan
  Tue Nov 18 20:49:30 2014 The RT System itself - Status changed from 'new' to 'open'
  Wed Nov 19 13:58:15 2014 victor [...] vsespb.ru - Correspondence added
Show quoted text
> > Now, suppose that we checked the return value of 'syswrite' at the > location cited. What would be the appropriate action if it were > 'undef'? >
Probably die. But problem is not when it returns undef, but when it returns undef and $!{EINTR} is set, that means there is no error, and you should retry read. Otherwise file will be partially copied. I think $!{EINTR} could happen if there were signal handlers installed and signals received. So either this should be fixed, or documented that callers should not use signals.