[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/usr.bin/make
On Sat, Jan 26, 2013 at 10:53:00AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Jan 26 15:53:00 UTC 2013
> Modified Files:
> src/usr.bin/make: job.c main.c
> Log Message:
> Check read and write errors to avoid warnings from linux.
> XXX: Should we print an error and exit instead?
> To generate a diff of this commit:
> cvs rdiff -u -r1.164 -r1.165 src/usr.bin/make/job.c
> cvs rdiff -u -r1.204 -r1.205 src/usr.bin/make/main.c
I'd have been tempted to do:
int stupid_glibc_wont_let_us_ignore_the_result_of_write(int fd, const void
*buf, size_t len)
return write(fd, buf, len);
#define write(fd, buf,len)
stupid_glibc_wont_let_us_ignore_the_result_of_write(fd, buf, len)
Certainly the accesses to the pipes are very boring.
The read(childExitJob.inPipe, ...) definitely doesn't need checking at all.
The writes to it are NON_BLOCK (I think) - it is only used to wake from
poll() - the read is there to clear POLLIN.
The job token pipe is slightly more interesting - but it will only be full
if you try to do more jobs than the pipe size - and then you need to discard
a job token, not block.
I'm not sure, but I think that read/write can only return EAGAIN if they
are blocking, have transferred no data, and take a signal that is
If they have transferred some data they they have to return a partial count.
So if you care about the result you have to do far more than loop
for EAGAIN - adding such a loop is a bogus fix.
Not much point writing an error is you'vejust failed to write to stderr!
David Laight: david%l8s.co.uk@localhost
Main Index |
Thread Index |