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). Paul Slootman -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
