Re: [PATCH] use xread where we are not checking for EAGAIN/EINTR

From: Junio C Hamano <junkio@cox.net>
Date: Jan 5, 2007, 11:19 UTC
Message-ID: <7vvejlg1pg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1cb8699724ff000fbf0c14ba3e15031e@pinky>

Andy Whitcroft <apw@shadowen.org> writes:

Show 9 quoted lines

>     We have an xread() wrapper to help us with those nasty
>     interrupt returns and yet we fail to use it consistently.
>     This patch updates those plain read()'s which do not
>     have any handling for errors, or which treat those errors
>     as user visible fatal errors.
>
>     This feels right to me, but perhaps there is some good
>     reason that things are done this way ... if so could
>     someone elighten me.

Thanks.

I do not think any of the changes you did introduced new bugs, but I think some of them are still wrong. xread() protects us from EINTR happening before any byte is read, but it can still give a short read. Many callers have a loop like this:

	do {
        	size = xread(...);
                yet_to_go -= size;
	} while (yet_to_go);

but some are not (e.g. add_excludes_from_file_1() in dir.c expects xread() does not return before reading full buffer).