Re: using explicit_bzero - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: using explicit_bzero
Date
Msg-id 9ff665f5-bdd1-7aa5-9490-b77d95ef771f@2ndquadrant.com
Whole thread Raw
In response to Re: using explicit_bzero  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2019-07-30 07:58, Andres Freund wrote:
> I think it's better to have a pg_explicit_bzero or such, and implement
> that via the various platform dependant mechanisms.  It's considerably
> harder to understand code when one is surprised that a function normally
> not available is called, the buildsystem part is really hard to
> understand (with runtime and code filenames differing etc), and invites
> API breakages.  And it's not really more work to have our own name.

explicit_bzero() is a pretty established and quasi-standard name by now,
not too different from other things in src/port/.

>> +/*
>> + * Indirect call through a volatile pointer to hopefully avoid dead-store
>> + * optimisation eliminating the call.  (Idea taken from OpenSSH.)  We can't
>> + * assume bzero() is present either, so for simplicity we define our own.
>> + */
>> +
>> +static void
>> +bzero2(void *buf, size_t len)
>> +{
>> +    memset(buf, 0, len);
>> +}
>> +
>> +static void (* volatile bzero_p)(void *, size_t) = bzero2;
> 
> Hm, I'm not really sure that this does that much. Especially when the
> call is via a function in the same translation unit.

This is the fallback implementation from OpenSSH, so it's plausible that
it does something.  It's worth verifying, of course.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: using explicit_bzero
Next
From: Konstantin Knizhnik
Date:
Subject: Re: Global temporary tables