File name too long
jw schultz
jw at pegasys.ws
Tue Mar 11 19:29:02 EST 2003
On Tue, Mar 11, 2003 at 09:16:24AM +0100, Paul Slootman wrote:
> On Mon 10 Mar 2003, jw schultz wrote:
> >
> > Overall it looks like it should be an improvement. Getting
> > rid of all that code duplication is a real gain.
> >
> > The one thing that bothers me, also present in the current
> > code is the bit of changing and then restoring fname. That
> > complicates the code in ways that are prone to induce human
> > error (a problem with my hack). It would be better to just
> > use a scratch char array.
>
> I thought about that, but I learnt programming when 16kB total RAM still
> meant something :-), so I always try to program as efficiently as
> possible. Copying up to 4kB of data around (MAXPATHLEN) when that can be
> avoided makes me feel bad... It's relatively localized in this case, so
> it shouldn't be too big a problem. Besides, the original code also did
> it :-)
Yes the original code did it but it is just too easy to miss
that fact. That makes it too fragile for my liking. I too
learned programming on 4KB - 16KB systems and dislike waste but
this kind of messing with passed-by-reference data just isn't
a good idea except in fast-path or embedded situations.
with all the strcpy, snprintf, strchr ops a simple
fscratch = alloca(strlen(fname)+1);
strcpy(fscratch,fname);
won't be that much of an issue on modern processors and
systems.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: jw at pegasys.ws
Remember Cernan and Schmitt
More information about the rsync
mailing list