pthreads in guid.c break compile

[Linas Vepstas]

I agree with Derek, small buffers on stack are harmless.  Anything under
a few KB on stack is harmless.  I'm not sure about glibc, but
some implementations of pthread_getspecific are cpu-sucking. 

I'm not sure, but, I think if we convert guid_to_string to 
return char[32] instead of char *, then the compiler will perform
an implicit copy-of-return-value in that magic compiler way,
without should be enough to get the printfs working without a memory
leak and without a static buffer. 

viz.

char[GUID_ENCODING_LENGTH] guid_to_string(const GUID * guid)
{
	char str[GUID_ENCODING_LENGTH];
	guid_to_string_buff(guid,str);
   return str;
}

Hmmmm... 
The above works in C++ but appearently not C, I just tried it, 
bummer.   

However, the following works in C.  According to the theory
of the C language, it should work with any compiler. 
Note that the value of a block {...} is the value of the last statement
of a block. Note that ({...}) is needed to get at that value. 

typedef struct { char str[GUID_ENCODING_LENGTH]; } block_t;
block_t hack_guid_to_string(const GUID * guid) {
	block_t b;
	guid_to_string_buff(guid, &b.str[0]);
	return b;
}

#define guid_to_string(g) ({block_t bl; bl=hack_guid_to_string(g); &bl.str[0]; })

main () {
char * str;
printf ("the value is %s\n", guid_to_string(guid));
str = guid_to_string(guid);
printf (" its also %s\n", str);
}

The above automatically puts the string onto the stack, and 
is completely thread-safe.  Anyone care to test & drop into CVS?

Its a little dirty-looking, but its makes the printf's use nice,
and is otherwise just a 'deprecated' function anyway.  Its nicer than
pthread_xxx

--linas




On Tue, Jul 01, 2003 at 11:29:06AM -0400, Derek Atkins was heard to remark:
> Well, personally I think smattering a bunch of (relatively small)
> buffers around the stack isn't a big deal..  I only suggested TLS
> because you didn't like the solution of spattering a bunch of
> (relatively small) buffers around.  If the choice is static buffer
> or TLS I'll take TLS...  But I still maintain that I'd prefer the
> smattering of buffers.
> 
> -derek
> 
> David Hampton <hampton at employees.org> writes:
> 
> > On Mon, 2003-06-30 at 17:40, Matthew Vanecek wrote:
> > > To Derek's point, is pthreads the desired direction? 
> > 
> > I don't know.  I was just trying to fix a memory leak.  Derek's the one
> > who insisted that I use thread local storage, which to me means
> > pthreads.  It was either that or splatter single use character arrays
> > across the code base, which seems like entirely the wrong approach to
> > me.  As far as whether we should be using pthreads, I'll go with
> > whatever group consensus is.  
> > 
> > David
> > 
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at lists.gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        warlord at MIT.EDU                        PGP key available
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at lists.gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933