Re: CVS commit: src/usr.bin/make

[David Laight <david%l8s.co.uk@localhost>]

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
restartable.

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

-- 
David Laight: david%l8s.co.uk@localhost