Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!seismo!esosun!cogen!celerity!celit!hutch
From: hutch@fps.com (Jim Hutchison)
Newsgroups: comp.unix.wizards
Subject: (4.3) hp.c, EINVAL vs. EOF/short-i/o
Keywords: 4.3 disk question
Message-ID: <589@celit.com>
Date: 28 Aug 89 17:32:27 GMT
Sender: daemon@fps.com
Reply-To: hutch@fps.com (Jim Hutchison)
Organization: FPS Computing
Lines: 37

<>
This relates to reading from the raw disk device, and what happens to I/Os 
which have a block spanning the end of a disk partition.

I have been working on a 4.3 derived Unix, and came across what I think is an
odd algorithm.  I looked in the 4.3 source from which it was derived, and found
the same algorithm.  The algorithm in place is as follows:

InPlace:
	if first block < 0 or first + size of i/o > end-of-partition
	    if first block == end-of-partition
		residual = byte count
		done
	    give the user an EINVAL
	    done
	actually do I/O
	done

What I expected was more like this:

Imagined:
	if first block < 0
	    give the user an EINVAL
	    done
	if first + size of i/o > end-of-partition
	    size = end-of-partition - first + 1;
	    residual = bcount - (size << 9);
	    bcount = size << 9;
	if bcount
	    actually do I/O
	done

Can anyone tell me why the InPlace algorithm is there?  Is there some
reason that I am unaware of?

/*    Jim Hutchison   		{dcdwest,ucbvax}!ucsd!celerity!hutch  */
/*    Disclaimer:  I am not an official spokesman for FPS computing   */