From mboxrd@z Thu Jan 1 00:00:00 1970 From: crossd@gmail.com (Dan Cross) Date: Wed, 16 Jul 2014 10:56:57 -0400 Subject: [TUHS] the sin of buffering [offshoot of excise process from a pipeline] In-Reply-To: <20140716143039.GA31888@mcvoy.com> References: <201407152343.s6FNhnUT001960@coolidge.cs.dartmouth.edu> <20140716003220.GA24974@mcvoy.com> <20140716035303.GO10065@mercury.ccil.org> <20140716040509.GA27375@mcvoy.com> <20140716060358.GP10065@mercury.ccil.org> <20140716143039.GA31888@mcvoy.com> Message-ID: Why can't those be embedded in the relevant string? freopen(fp, "rx{128}") or something? On Wed, Jul 16, 2014 at 10:30 AM, Larry McVoy wrote: > On Wed, Jul 16, 2014 at 02:03:58AM -0400, John Cowan wrote: > > Larry McVoy scripsit: > > > > > We tried that but the problem is that you can't encode all the options > you > > > want in just a character. Compression doesn't take options, the > CRC/XOR > > > layer wants to know how big you might think the file is (because we > > > support blocksizes from about 256B to 256K and we want to know the > > > file size to guess the block size). > > > > It's a string: you can have as many characters as you want. > > I understand your desire to have one API. We tried and it just wasn't > practical. Imagine pushing an encryption layer that wants a key, > XOR layer that wants block size, etc. > _______________________________________________ > TUHS mailing list > TUHS at minnie.tuhs.org > https://minnie.tuhs.org/mailman/listinfo/tuhs > -------------- next part -------------- An HTML attachment was scrubbed... URL: