[Date Prev][Date Next]
Re: FW: is the ssl3_send_alert() function public ( part of the API )? (ITS#1954)
>>From: Kervin L. Pierre [mailto:email@example.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 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.