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

[kervin@blueprint-tech.com]

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 
`-S'.

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.

Respectively,
--Kervin