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
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
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
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
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
> 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.
./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
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
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);
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?).
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
>
>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
12 matches
Mail list logo
