PostgreSQL, OpenSSL, and the GPL

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

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.

to post comments

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.