(4.3) hp.c, EINVAL vs. EOF/short-i/o

[Chris Torek]

In article <589 at celit.com> hutch at fps.com (Jim Hutchison) writes:
>... I looked in the 4.3[BSD] source from which it was derived, and found
>the same algorithm ...:
>
>	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

Yes, this is what it (and others) do.  Sometimes the EINVAL changes.

>What I expected was more like this:
>
>	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 [other] algorithm is there?

Primarily laziness.

The 4.3BSD-tahoe vaxmba/hp.c has something closer to the second
algorithm, except that it does this:

	if (bp->b_blkno < 0 || bp->b_blkno + sz > maxsz) {
		if (bp->b_blkno == maxsz) {
			bp->b_resid = bp->b_bcount;
			goto done;
		}
		sz = maxsz - bp->b_blkno;
		if (sz <= 0) {
			bp->b_error = EINVAL;
			goto bad;
		}
		bp->b_bcount = sz << DEV_BSHIFT;
	}

which does the wrong thing if b_blkno is negative.  I tried to
convince Mike that the third test should be

	if (bp->b_blkno < 0 || (sz = maxsz - bp->b_blkno) <= 0)

but the code on okeeffe is still wrong.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris