Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!ulysses!ggs
From: ggs@ulysses.homer.nj.att.com (Griff Smith)
Newsgroups: comp.unix.questions
Subject: Re: SunOS 3.5 dd (ibs == obs) != bs
Summary: fast path, yes; hack, no
Keywords: Bug or Feature
Message-ID: <10842@ulysses.homer.nj.att.com>
Date: 11 Nov 88 16:45:28 GMT
References: <37@eplrx7.UUCP> <429@auspex.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 36

In article <429@auspex.UUCP>, guy@auspex.UUCP (Guy Harris) writes:
> The S5R3 "dd", although it has all the V7/BSD "dd" features, doesn't
> have the "fflag" hack - it may copy stuff more efficiently and thus not
> bother with that particular fast path.  Griff?

I didn't use the fflag hack.  The strategy on the new one is to assume
that a simple read-write loop will work until proven otherwise.  For
otherwise, a large switch selects one of 28 separately coded conversion
loops to process each input block.  If the fast path isn't suppressed,
the conversion dispatch loop falls into this case after doing a `read'
(flsh flushes the output buffer):

/* Simple copy: no conversion, preserve the input block size */

		case COPY:
                        obc = ibc;
			(void)flsh();
			break;


The following conditions suppress the fast path:

1) A zero value for the `bs' option

2) Any data conversions other than `swab', `noerror' and `sync'.

The V9 Research Unix System version takes this one step further: it uses
the fast path if ibs == obs (at least it did the last time I checked).
I think this is wrong, it increases the chance that I will write a tape
that has the wrong block size; I have to remember to use an ibs that is
!= obs to force obs to be what I intend.
-- 
Griff Smith	AT&T (Bell Laboratories), Murray Hill
Phone:		1-201-582-7736
UUCP:		{most AT&T sites}!ulysses!ggs
Internet:	ggs@ulysses.att.com