On Mon, Aug 1, 2011 at 11:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Attached is a try at that approach.
>
> I don't find this to be a particularly safe idea:
>
>> #ifndef HAVE_ERAND48
>> -/* we assume all of these are present or missing together */
>> -extern double erand48(unsigned short xseed[3]);
>> -extern long lrand48(void);
>> -extern void srand48(long seed);
>> +#define erand48(x) pg_erand48(x)
>> +#define lrand48() pg_lrand48()
>> +#define srand48(x) pg_srand48(x)
>> #endif
>
> See our recent trials with python headers for an example of why this
> might cause problems on some platforms. For that matter, I believe
> <stdlib.h> would be within its rights to be defining these names as
> macros already.
If HAVE_ERAND48 isn't defined and erand48() is nevertheless defined as
a macro, it's a bug in the autoconf test for erand48(). The whole
point is to do that only when there isn't any erand48(). But we could
dodge the issue at any rate by making erand48(), lrand48(), and
srand48() functions that call pg_erand48(), pg_lrand48(), and
pg_srand48() rather than macros. And I'd rather do that than this,
honestly:
> If you want erand48_r, best to provide that API, not kluge up some
> other functions.
...because erand48() is a GNU extension with a stupid API. I don't
see much value in supporting that, on both counts. We're going to end
up with the built-in erand48_r() on precisely those systems that use
glibc, and our own everywhere else. For the 25 SLOCs it's going cost
us, I'd rather use the same code everywhere.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company