fix to my SEGFAULTs on redhat 7.2

[Ben F]

I posted a while back about having SEGFAULT problems with
cfengine (2.0.1 back then) on redhat 7.2 machines. I had managed to
stop it by not using purge, but recently I needed to turn purge
back on, and the problem came back in force. 
[This is with 2.0.2 now]

If I don't use purge in my /etc copyfiles section, I'm getting SEGFAULT 
maybe 30% of the time. With purge on, I was getting it 100% of the 
time at the same place! Which is why I finally had to look at it since
no one else seems to be having this level of trouble with cfengine. 
I've been using cfengine for several years FYI.

So I've ended up going through the code with gdb, and this
is what I've found. Please note that I haven't done any real
C programming since the 80's except for the occasional
porting of things.

Anyway, the problem seems to be with the global variable
'DESTINATION'.
My crash was occuring in the AbsLinkPath() call in the
LinkFiles() routine. Evidentally the DESTINATION variable
is used as a place to hold stuff w/o having to setup
and the free the space all the time, at least that is what this
comment leads me to think:

strcpy(DESTINATION,from);  /* reuse to save stack space */

DESTINATION is malloc'd in NewParser(),
and free'd in DeleteParser(). In addition this step is done in
InitializeAction():
    *DESTINATION = '\0';
However, my debugging indicates that the DeleteParser()
is happening after the various config files are parsed - no
suprise there - except that DESTINATION is also used in
the AbsLinkPath() routine farther down the road - so to speak.

DESTINATION is also used in various routines in install.c.


As I don't remember much about scope of variables in C, and
certainly know nothing about pthreads, I just added the following
lines in link.c:

diff -r1.1 link.c
1179a1180,1182
> 
>   DESTINATION = (char *) malloc(bufsize);
>   bzero(DESTINATION,bufsize);

Presto chango, no more core dumps. However, I'm pretty sure
the malloc should be done somewhere more global since 
DESTINATION is used in other places. And probably the
routines in parse.c shouldn't be doing stuff with 
DESTINATION since it is a global.

Can someone take a look over this and if this seems
correct?

thanks,
Edgar Nielsen