> On Thu, Nov 06, 2003 at 04:44:22PM -0800, Paul Eggert wrote:
> > Yes, I'd say a new one. It's more of a pain, but it's the "right way"
> > to do it.
>
> Perhaps the following patch is acceptable?
Hello,
Is there any feedback or progress related to this patch? I'm very
eagerly awaiting a copy
Hello Paul,
On Thu, Nov 06, 2003 at 04:44:22PM -0800, Paul Eggert wrote:
> Yes, I'd say a new one. It's more of a pain, but it's the "right way"
> to do it.
Perhaps the following patch is acceptable?
Best regards,
-Neill.
diff -N -P -r -u --exclude='aclocal*' --exclude=Makefile.in --exclude
Hello Paul,
On Thu, Nov 06, 2003 at 12:03:46PM -0800, Paul Eggert wrote:
> Suppose we just split out buffer_lcm into a separate module and use
> that?
Thanks again for the feedback. I've taken a look at this and the
buffer_lcm method is concise and more robust than the proposed ones.
So I'm cert
Hello,
On Wed, Nov 05, 2003 at 04:35:50PM -0800, Paul Eggert wrote:
> I'd put it into the lib directory, so that the code can be shared.
> Also, it should take and return size_t, not unsigned int.
Below is a proposed patch that addresses these issues. Again, your
comments are appreciated.
Best
On Tue, Nov 04, 2003 at 05:50:31PM -0800, Paul Eggert wrote:
> Surely it should use the least common multiple of the two block sizes?
>
> (Checking for overflow, of course.)
Hello Paul,
Thanks for your feedback. From an organizational standpoint, is it
appropriate to re-use the lcm routine resi
Hello,
I've ran into an issue with using the 'cp' tool. In short, I was
wondering why the optimal buffer size (as noted in comments) for a
copy is the destination block size (as reported by fstat) instead of
the maximum of the source and destination block sizes.
Imagine the following scenario:
