rsync 2.5.5 SCO Unixware patch

[jw schultz]

On Tue, Dec 24, 2002 at 07:26:38AM -0600, Dave Dykstra wrote:
> On Mon, Dec 23, 2002 at 11:42:07PM -0800, Jos Backus wrote:
> > On Mon, Dec 23, 2002 at 02:13:51PM -0800, Stephen Friedl wrote:
> > > The change in popt/popt.c is to work around a bug in the SCO UNIXWare 8
> > > compiler: it doesn't properly deal with alloca() being called from the
> > > middle of another function call. The code dumps badly on this platform
> > > with all modes (debug, regular, optimized), and the workaround shown
> > > gets around the bug and likely obviates similar bugs on other platforms.
> ...
> > > --- popt/popt.c.orig    Mon Dec 23 21:51:59 2002
> > > +++ popt/popt.c Mon Dec 23 21:59:21 2002
> > > @@ -443,9 +443,10 @@
> > >             }
> > >  
> > >             /* Make a copy we can hack at */
> > > -           localOptString = optString =
> > > -                       strcpy(ALLOCA(strlen(origOptString) + 1),
> > > -                       origOptString);
> > > +           { int n = strlen(origOptString) + 1;
> > > +             localOptString = optString = ALLOCA(n);
> > > +             strcpy(optString, origOptString);
> > > +           }
> > >          
> > >             if (!optString[0])
> > >                 return POPT_ERROR_BADOPT;
> ...
> > I don't feel brave enough to commit the popt/popt.c change without input from
> > others.
> 
> 
> The patch seems harmless, although I'm not sure it's the best style.
> How about making strcpy a macro instead?  popt/popt.c is borrowed code,
> and if we make modifications to it it might get forgotten the next time
> it is upgraded.
> 
> - Dave Dykstra

I share Dave's misgivings regarding mucking with borrowed
code like that.  It tends to cause version lock or
regression.  Heck, i prefer to accept library dependencies
to dropping in foreign code :)  If the UNIXWare compiler
can't handle the construct Stephen could forward the patch
to the libpopt project and file a bug report with SCO.
That said if we want this i'd be inclined to have a patch
that fixes this as part of the build process (perhaps with a
popt.c.orig) so we have the fix directly documented for
future forward ports.

Also of concern is that the patch is against 2.5.5 not cvs
which is noticeably different.  I wouldn't expect the patch
to apply.

I'm not sure i'd turn it into a strcpy macro.  This is
allocating on the stack so it doesn't need a free and the
allocated space will get trashed on return.  Using the macro
without full awareness of the semantics would open the door
to bugs that could be intermittent.

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

		Remember Cernan and Schmitt