vbcc proto/inline issues about amissl

[Futaura]

You mention "normal" a lot - unfortunately OpenSSL is not normal!

The helper functions are defined that way in OpenSSL, as static inline functions. Macros could in theory be used instead, but then you'd lose all the type checking and tracing, which would make debugging difficult. Unfortunately, VBCC does not have an "inline" keyword for forcing functions to be inlined, unlike GCC (and SAS/C incidentally), so I guess -O3 is your only option there.

As these inline functions simply call OpenSSL functions, AmiSSLBase has to be a global variable - I don't see a way around that.

One alternative to inline functions would be to create a link library instead, but still this approach would require AmiSSLBase to be a global variable too, if those functions are used.

[Futaura]

BTW, I guess you could try the following, if you do not need those helper functions:

#define AMISSL_INLINE_H
#include <proto/amissl.h>

Everything in amissl/inline.h is actually a copy of the corresponding code from openssl/safestack.h and openssl/lhash.h, so that's where those inline functions originate in OpenSSL.

[patrikaxelsson]

Thank you very much - when AMISSL_INLINE_H is defined, none of the issues mentioned above appear when including proto/amissl.h:

$ make EmptyAmiSSLTest EmptyAmiSSLTest_O3 LocalBaseAmiSSLTest
vc +aos68k -nostdlib -c99 -O2 -lvc -DAMISSL_INLINE_H -IAmiSSL/Developer/include -o EmptyAmiSSLTest EmptyAmiSSLTest.c
vc +aos68k -nostdlib -c99 -O3 -lvc -DAMISSL_INLINE_H -IAmiSSL/Developer/include -o EmptyAmiSSLTest_O3 EmptyAmiSSLTest.c
vc +aos68k -nostdlib -c99 -O2 -lvc -DAMISSL_INLINE_H -D__NOLIBBASE__ -IAmiSSL/Developer/include -o LocalBaseAmiSSLTest LocalBaseAmiSSLTest.c
$ ls -la EmptyAmiSSLTest EmptyAmiSSLTest_O3 LocalBaseAmiSSLTest
-rwxr-xr-x  1 patrik  access_bpf  56  4 Sep 00:19 EmptyAmiSSLTest*
-rwxr-xr-x  1 patrik  access_bpf  56  4 Sep 00:19 EmptyAmiSSLTest_O3*
-rwxr-xr-x  1 patrik  access_bpf  40  4 Sep 00:19 LocalBaseAmiSSLTest*

The https.c example included in AmiSSL builds with AMISSL_INLINE_H defined (and works), so I guess it is still functional enough for common use without those helper functions?

[Futaura]

Sure. You'd get a linker error anyway if the code you are compiling actually needs those functions. IBrowse needs them for user certificate handling, for example, but for basic HTTPS they are not required.

[patrikaxelsson]

Would it perhaps be sensible to make amissl/inline.h an opt-in include instead, as it is not needed in the general case and it gives these side-effects?

Apart from the unexpected behavior, the build time and memory consumption makes it impossible or very impractical to build on a real Amiga.

[Futaura]

@patrikaxelsson I don't think so. I think we need to leave the maximum OpenSSL compatibility enabled by default.

I can compile IBrowse perfectly fine for OS3 with SAS/C on my A1200 and for OS4 with GCC on my A1XE, without needing to disable these headers (in fact, IBrowse needs some of those functions). AmiSSL itself is even buildable on my A1XE.

I shall keep this in mind with OpenSSL 3.0 though, which I am currently trying to port - at first glance, it seems they've made the safestack/lhash inline stuff even more complicated, but we shall see.

[patrikaxelsson]

AMISSL_INLINE_H worked great as a workaround for this issue in 4.x, closing.