./config -fkeep-inline-functions && make
-> build fails with unresolved externals in test/rsa_complex and 
test/shlibloadtest

On 1/27/19 2:23 PM, Dr Paul Dale wrote:
> Yes, those are the problematic cases.  I think that making the symbols weak 
> is “good enough” for the moment.  Longer term, we could do with a better 
> solution.  Moving the implementations into another file is one option.  There 
> is another longer term alternative: migrate OpenSSL away from lhash and 
> safestack by introducing new internal functionality that replaces them.  We 
> can’t remove either in case users user them but we could stop using them 
> ourselves.
> 
> Lhash is based on a clever hash table that dynamically resizes (both 
> increasing and decreasing) and amortises the rehashing costs over time.  If 
> the OpenSSL source code is looked through, there are relatively few removals 
> from the hash table.  I.e. the size decrease isn’t used much, if at all.  
> Likewise, the rehashing checks one bit in the hash for each item and moves it 
> into one of two lists based based on the result.  I.e. rehashing should be a 
> fast operation and amortising it doesn’t feel like a win.  On the down side, 
> lhash runs with a fairly high level of loading (many entries relative to 
> table size) and its collision resolution is a linked list (i.e. O(n) worst 
> case instead of O(1)).  There have also been improvements in hash technology 
> since the lhash algorithm was created — cache coherent algorithms and lock 
> free ones spring to mind.
> 
> Safestack isn’t a stack anymore.  It is used as a vector, an array 
> substitute, a queue and more.  I don’t think I’ve seen it used as a stack but 
> it probably is.  We should have separate data structures for the different 
> uses, each optimised for its specific usage.
> 
> 
> This would be a long path (and I’m hijacking this thread a bit), but it is 
> something I’ve been wanting to do for a while now.
> 
> 
> Pauli
> 
> 
> _______________________________________________
> openssl-project mailing list
> openssl-project@openssl.org
> https://mta.openssl.org/mailman/listinfo/openssl-project
> 
_______________________________________________
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project

Reply via email to