Re: [openssl-project] inline functions

2019-01-27 Thread Richard Levitte
You're talking about these lines from safestack.h: DEFINE_SPECIAL_STACK_OF(OPENSSL_STRING, char) DEFINE_SPECIAL_STACK_OF_CONST(OPENSSL_CSTRING, char) DEFINE_SPECIAL_STACK_OF(OPENSSL_BLOCK, void) and these from lhash.h: DEFINE_LHASH_OF(OPENSSL_STRING);

Re: [openssl-project] inline functions

2019-01-27 Thread Bernd Edlinger
./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

Re: [openssl-project] inline functions

2019-01-27 Thread Dr Paul Dale
I’d generally prefer functions over macros — I think that the ctrl calls e.g. would be better wrapped with function to provide type checking. The overhead of a function call is pretty light these days so inline functions are difficult to justify (as anything except a premature optimisation?).

Re: [openssl-project] inline functions

2019-01-27 Thread Kurt Roeckx
On Sun, Jan 27, 2019 at 08:33:06PM +1000, Tim Hudson wrote: > From https://github.com/openssl/openssl/pull/7721 > > Tim - I think inline functions in public header files simply shouldn't be > present. > Matt - I agree > Richard - I'm ambivalent... in the case of stack and lhash, the generated >

[openssl-project] inline functions

2019-01-27 Thread Tim Hudson
>From https://github.com/openssl/openssl/pull/7721 Tim - I think inline functions in public header files simply shouldn't be present. Matt - I agree Richard - I'm ambivalent... in the case of stack and lhash, the generated functions we made static inline expressly to get better C type safety, and

Re: [openssl-project] inline functions

2019-01-27 Thread Dr Paul Dale
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

Re: [openssl-project] inline functions

2019-01-27 Thread Richard Levitte
On Sun, 27 Jan 2019 18:51:58 +0100, Viktor Dukhovni wrote: > > > On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: > > > > Tim - I think inline functions in public header files simply shouldn't be > > present. > > I think they have their place, and we should try to make them more portable > to

Re: [openssl-project] inline functions

2019-01-27 Thread Dr Paul Dale
Isn’t this going to run into the same issues? The DEFINE_ expansions need to be in their own .c file (one file with all or one file per, I’m not fussed much but the latter seems nicer). The DEFINE_ macros need to stay in the header for compatibility. To handle the external linkage, a new

Re: [openssl-project] inline functions

2019-01-27 Thread Viktor Dukhovni
> On Jan 27, 2019, at 5:33 AM, Tim Hudson wrote: > > Tim - I think inline functions in public header files simply shouldn't be > present. I think they have their place, and we should try to make them more portable to less capable toolchains as needed. -- Viktor.

Re: [openssl-project] inline functions

2019-01-27 Thread Dr Paul Dale
Richard wrote: > Not really, since they are static inline. This is by design, that for any > file you want to use a safestack in, you just start with a DEFINE_ line. The > mistake we did was to leave a few common ones in the safestack header file. > (same thing for lhash) Which means we’ve a

Re: [openssl-project] inline functions

2019-01-27 Thread Richard Levitte
Dr Paul Dale skrev: (27 januari 2019 23:18:06 CET) >Isn’t this going to run into the same issues? No. It's the expansion of the macros that causes the problem, not the macros themselves. So if you move the expansions to the .c that actually use stacks / lhashes, they should obviously be

Re: [openssl-project] inline functions

2019-01-27 Thread Richard Levitte
On Mon, 28 Jan 2019 06:17:35 +0100, Dr Paul Dale wrote: > Richard wrote: > > Not really, since they are static inline. This is by design, that for any > file you want to use > a safestack in, you just start with a DEFINE_ line. The mistake we did > was to leave a few > common ones