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 <[EMAIL PROTECTED]> 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
> > [EMAIL PROTECTED]
> > http://www.gnucash.org/cgi-bin/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
> [EMAIL PROTECTED] PGP key available
> _______________________________________________
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
--
pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <[EMAIL PROTECTED]>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
