[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: FW: is the ssl3_send_alert() function public ( part of the API )? (ITS#1954)

hyc@highlandsun.com wrote:
>>-----Original Message-----
>>From: Kervin L. Pierre [mailto:kervin@blueprint-tech.com]
>>Well at least we are on the same page about the function being private.
> I let that slide, but in fact there are several exported functions whose
> names begin with lower-case chars. The distinction is not as concrete as
> you would be led to believe.

Still does not take away from the fact we know this one is private.

>>The current issue is, can we trust that it is safe to continue using
>>this OpenSSL private function.
>>I think generally using any functions not explicitly part of the API is
>>a risky venture.  This is generally speaking, but I think it is a good
>>policy to avoid this.
> Perhaps so; your definition of what is part of the API differs from mine.
> Since I had a hand in creating the OpenSSL API I trust my definition more
> than yours.

Good for you.  I was not trying to belittle your achievements, my 
apologies if it sounded that way.

>>Also if OpenSSL programmers start only exporting the API functions (
>>believe you can do this with most ld's, it's just not the default ), we
>>would lose this function as well.
> This is not a standard feature of Unix linkers. You cannot extrapolate how
> the world works (or should work) based on the example set by Microsoft.

from the GNUL ld manpage...

--retain-symbols-file filename
Retain only the symbols listed in the file filename, discarding all 
others. filename is simply a flat file, with one symbol name per line. 
This option is especially useful in environments (such as VxWorks) where 
a large global symbol table is accumulated gradually, to conserve 
run-time memory. `--retain-symbols-file' does not discard undefined 
symbols, or symbols needed for relocations. You may only specify 
`--retain-symbols-file' once in the command line. It overrides `-s' and 

Another option is the filter object.

But this is straying from the point.

>>What were OpenLDAP API users who relied on the LDAP connection structure
>>members being directly accessible told?  A very hash "you shouldn't be
>>doing this!" :)
> In the first UMich API, using the LDAP connection structure was *the*
> documented way to interact with the library, as no accessor functions
> existed. This is also a poor example.

I what it was.  But that's not the case any more, and on many occasions 
I've seen that particular response to users you tried that.

>>Anyhow, it's a very minor issue so I'm going to stop spamming the list
>>about it now.
> Thank you.
>>But it still breaks the MSVC build :(
> As I said before, it works with MinGW, and the fix is trivial. Get over it.

Please Howard, don't get confrontational about this.  My objection in 
using the function is *not* a personal attack, just my professional 
opinion.  And I could be wrong.

I was only pointing out a build issue.  I know that you don't like the 
MSVC build, but a few of us are trying to use it.

The final decision is yours since you maintain the code, feel free to go 
in what direction you please with this.