PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 6:16 UTC (Sat) by dvdeug (subscriber, #10998)
In reply to: PostgreSQL, OpenSSL, and the GPL by butlerm
Parent article: PostgreSQL, OpenSSL, and the GPL

All of an ordinary header file is included in the code that is sent to the compiler. How you define included in the resulted binary I don't know; usually none of the text of code is included in the output, except for function names, like those included in the header. If you're only including code, the following define from openssl/engine.h compiles a function into the binary of the program instead of keeping it into the library.

#define IMPLEMENT_DYNAMIC_BIND_FN(fn) \
OPENSSL_EXPORT \
int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \
if(ENGINE_get_static_state() == fns->static_state) goto skip_cbs; \
if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \
fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \
return 0; \
CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \
CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \
CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb); \
CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \
CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb); \
if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \
return 0; \
if(!ERR_set_implementation(fns->err_fns)) return 0; \
skip_cbs: \
if(!fn(e,id)) return 0; \
return 1; }

to post comments

PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 17:01 UTC (Sat) by butlerm (subscriber, #13312) [Link] (2 responses)

I said an "ordinary" header file for a reason. Inline functions of any sophistication are clearly an exception. They are also pretty much useless for any library that wants to maintain binary compatibility.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 23:07 UTC (Sat) by nix (subscriber, #2304) [Link]

Not necessarily. I've written a good few headers which define convenience functions as static functions in the header file, which only call other public functions with guaranteed API/ABI. This makes them inlinable even if the bulk of the library is in a shared object and thus not amenable to cross-translation-unit inlining from its users, while simultaneously being quite safe compatibility-wise: if the functions they call break, they'd break for all their other users too. The only real downside is that bugs fixed in those functions will not be reflected by their users until those users are recompiled.

Static functions in the header which mess with non-API-guaranteed stuff are exactly as bad as allowing your users to mess with such stuff in the first place. In both cases, the answer is the same: Don't Do That.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 23, 2011 22:44 UTC (Wed) by dvdeug (subscriber, #10998) [Link]

But that is part of the code that libssl may compile into your program. Glibc will compile similar chunks into your code; see bits/stdlib.h. Or libpng/png.h where png_composite is a small chunk of inline code. There's enough of these files to say that to exclude these from being "ordinary" header files, /usr/include has an awful lot of header files that are or include superordinary files.