Skip site navigation (1) Skip section navigation (2)

Re: libpq not reentrant

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Federico Di Gregorio <fog(at)initd(dot)org>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: libpq not reentrant
Date: 2002-01-18 16:04:08
Message-ID: 6778.1011369848@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Federico Di Gregorio <fog(at)initd(dot)org> writes:
> so the right library is already detected. the function is called
> des_crypt and is completely compatible with std. i think that a

>   AC_SEARCH_LIBS(crypto,  des_crypt)

> in configure.in will suffice. then:

>   #ifdef HAVE_DES_CRYPT
>   #define crypt des_crypt
>   #endif

Hmm.  If it uses the same API as crypt(), how can it be reentrant ---
is it malloc'ing the result string?  The resulting leak probably isn't
significant for libpq's purposes, but I'm curious to know.

> in the right file will do the trick. (i know this is not a real patch,
> sorry. i can make one later at home if you need.)

Please put together and test a complete patch.  I don't really care for
the #define crypt, BTW --- seems too likely to cause problems.  I'd
suggest #ifdef'ing around the call to crypt().

Also, if the result string is malloc'd, code along the lines of

	#ifdef HAVE_DES_CRYPT
		foo = des_crypt(...);
	#else
		foo = crypt(...);
	#endif

		... use foo ...

	#ifdef HAVE_DES_CRYPT
		/* des_crypt returns malloc'd string */
		free(foo);
	#endif

doesn't seem too unreasonable.  Or even

	#ifdef HAVE_DES_CRYPT
		foo = des_crypt(...);
	#else
		foo = strdup(crypt(...));
	#endif

		... use foo ...

		free(foo);

which would at least narrow the window for problems when using
non-reentrant crypt.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Bruce MomjianDate: 2002-01-18 17:21:06
Subject: Re: libpq not reentrant
Previous:From: Federico Di GregorioDate: 2002-01-18 15:46:47
Subject: Re: libpq not reentrant

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group