File name too long

[jw schultz]

On Tue, Mar 11, 2003 at 09:51:42AM +0100, Paul Slootman wrote:
> On Tue 11 Mar 2003, jw schultz wrote:
> > On Tue, Mar 11, 2003 at 09:16:24AM +0100, Paul Slootman wrote:
> > > > 
> > > > 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.
> 
> Hmm, OK, I guess you've convinced me...
> 
> > 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.
> 
> I was thinking about alloca(), but I didn't see it used anywhere in the
> main rsync code, so I thought that perhaps alloca() is bad for the
> portability. I remember I used to hate code where alloca was used, as
> my SysVR2 systems didn't have alloca (and gcc didn't work there either).

That or char fscratch[MAXPATHLEN];
Just don't use malloc.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt