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

Re: leakproof

From: Christian Ullrich <chris(at)chrullrich(dot)net>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: leakproof
Date: 2012-02-23 08:17:06
Message-ID: ji4sm2$5d2$1@dough.gmane.org (view raw or flat)
Thread:
Lists: pgsql-hackers
* Andrew Dunstan wrote:

> Returning to the original point, I've come to the conclusion that
> "pure" isn't the right way to go. The trouble with "leakproof" is that
> it doesn't point to what it is that's not leaking, which is
> information rather than memory, as many might imagine (and I did)
> without further hints. I'm not sure any single English word would be
> as descriptive as I'd like.

Jumping into the bikeshedding here, I'm not convinced that all that 
many users would immediately jump to the wrong conclusion (that being 
"free of memory leaks"). Rather the opposite, indeed.

IMHO, you may be looking at this through "C developer colored 
glasses", where any "leak" must immediately and without doubt be a 
resource leak of some kind. As Don Baccus pointed out, it would be a 
highly unusual function that was not at least intended to be free of 
memory leaks.

A DBA, on the other hand, might -- and, again, this is MHO only -- not 
decide what the attribute must mean without consulting the 
documentation. If she was especially concerned about information 
security/data protection, she might even guess right about what kind 
of "leak" is meant. There is no chance of that with terms like SILENT 
or PURE.

Of all the suggestions I have seen in this thread, I think LEAKPROOF 
is actually the best fit for the purpose. My favorite alternative, 
just to suggest one, would be NONDISCLOSING/NOT DISCLOSING, but I 
prefer LEAKPROOF even over that, not just because it's shorter.

-- 
Christian Ullrich



In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-02-23 08:23:11
Subject: Re: Commit a445cb92 not tested without OpenSSL support?
Previous:From: Gianni CiolliDate: 2012-02-23 07:15:28
Subject: Re: Triggers with DO functionality

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