🚀 go-pugleaf

Please observe the following (reduced) function and, below it,
a function returning pointer to char, which it calls:

void mark_cmp( char flag )
{
	int i;
	unsigned memleft;
	char sav_str[13], *p, *q;
	newfblk **f;
        ...
	f = fp;
	memleft = coreleft();
	for( i = 0; i < files; i++ ) {
		if( !((*f)->f_attrib & FA_DIREC) ) {
			p = (*f)->f_name;
			q = make_fn( p );  /*<big problems right here*/
                ...
		}
		f++;
	}
        ...
}
char *make_fn( char * file_name )
{
    int i;
    char *w, *p = file_name;
    char name[13];

    for( w = name; *p; p++ )
        if( *p != ' ' )
            *w++ = *p;                                  /*don't copy ws*/
    *w = '\0';
    return name;
}

make_fn receives a pointer to a file name prepared for display, 
that is, with spaces:

   fn     .ext

and changes it to 'fn.ext.'  The result is fine as it leaves
make_fn, but when we get back to mark_cmp, the string has 
been destroyed.  You may see only part of the name followed
by garbage (part of the name is lost), or you may see the
full name, but with trailing garbage, as though the terminating
null got lost.  I've tried a few modifications, to no avail.

I had handy a global string sufficient to hold the result, and
so to continue I have used that within make_fn instead of 'name',
and returned a pointer to that.  That works fine.

The program is compiled with TC 2, small model.  I really doubt
I've filled up the data segment, but don't have any way to
prove it (read: *I* don't know how to tell how much memory
is unallocated in the data segment).  If people suspect a
memory allocation problem, I might report that coreleft shows
around 32K left.  I don't know that that is within the data
segment.  (What sort of memory does coreleft report as "free?")

As long as I'm talking about memory, I might also complain that
I've had problems using TC malloc before; that is, I've had
experiences where I'd allocate a block of size N, put stuff in
it, then go to show it and find some junk in the space.  In all 
cases conversion to calloc fixed that problem.  Am I alone
in this?  But this is really a side complaint...

Please, fill my mbox with your ideas about why an apparently
good string upon exit from make_fn turns bad on return to
mark_cmp.

Thanks muchly.

-- 
Frank Burleigh  burleigh@cica.cica.indiana.edu
USENET: ...rutgers!iuvax!cica!burleigh BITNET: BURLEIGH@IUBACS.BITNET
Department of Sociology, Indiana University, Bloomington, Indiana 47405