Question

I’ll use openssl installed header structure for this example:

/usr/include       (or some folder in include search path on Windows box)
  |
  + --openssl
       |
       +-- e_os2.h
       +-- rsa.h
       +-- sha.h
      ...

/usr/include is in compiler include search path. OpenSSL header are commonly included this way: #include <openssl/sha.h>

As a first line, openssl/sha.h has this include: #include <openssl/e_os2.h>.
So, my question: is it really good idea for installed header to refer to header in the same folder that way? When it refers to e_os2.h that way it’s possible that it picks up e_os2.h from some other location, not necessarily in the same folder as sha.h. For example, if I had a local copy of openssl includes in some location and included that sha.h this way: #include "../../3rdpath/openssl/sha.h then I may get some nasty bugs in my code by combining incompatible version of headers.

Considering the fact that compilers behave differently regarding #incldue <...> vs #incldue "..." what would be proper way for a lib like openssl to include it’s headers?

I thought, that the way openssl does is the most wrong way to do it. The other two ways are:

a) #include "e_os2.h"

and

b) #include "./e_os2.h"

The openssl way is:

c) #include <openssl/e_os2.h>

Is that bad decision to do the way it’s done in openssl? Any problems with a) or b)? b) means to include e_os2.h only from the same folder, is that guaranteed with all major compilers (ms cl, armcc, intel cl, gcc et all)?

Answer 1

Your first option is the most open to doing the wrong thing; it’ll find files by the given name in packages of headers belonging to other libraries altogether. Your second one at best gives undefined behavior; I wouldn’t expect it to work most of the time. The third way is the correct way; it will only include openssl’s version of the file. If you arrange to replace some header by putting another incomplete openssl directory in your include path, then I’d assume you know what you’re doing.