Use of angle brackets around file names for include statements about libplist HOT 9 CLOSED

Is there any advantage to this? Three popular compilers, GCC, Visual Studio, and Clang, will prioritize searching the source file's directory for the header. Libplist uses double-quoted includes for internal headers which located in the same directory as their counterparts. At the least, it is an easy way to distinguish those includes from public headers. The name 'plist.h' is used for both a public and private header, so there is also a potential name collision.

from libplist.

I suggest to reconsider the consequences of the following wording from the section "16.2 Source file inclusion" in the standard specification for the programming language "C++".

…
The named source file is searched for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read

#include <h-char-sequence> new-line
…

• How do you think about to avoid "a duplicated file search" here?
• Would you like to restrict the searched directories for header files of your software?

from libplist.

I'm not a maintainer, so it is not my decision, I was just curious about the value of making the change. I read some of the Stack Overflow discussion you linked to, including the references to the standard. The interpretation of double-quotes may be implementation-defined, but from a pragmatic point of view, is there a common compiler that does not support that assumption that the current directory will be searched first?

There is no problem with duplicate file searches once the library is installed, as long as you build clients against the installed version (which is what the other libimobiledevice projects do). If you absolutely must build against the libplist source, you can add <libplist_root>/include/plist to your header search path and you will only find the public headers. Does that address both of your bullet points?

from libplist.

There are different opinions about the handling of the involved implementation-defined behaviour.

• Will header files be also searched outside the specified include directories if double quotes are used for the discussed preprocessor statement?
• Is there a speed difference measurable if a file is not found there and the search will be retried with "the angle brackets inclusion method"?

from libplist.

I must agree with @aburgh since we are not aware of any platform or compiler where the double quotes are a problem. @elfring If you can provide an example of where this is an issue please enlighten us. Otherwise I don't see a point in changing this.

from libplist.

I would generally prefer to exclude the potential for the inclusion of header files from unexpected directories. Can such a security detail become a bit more important?

from libplist.

On the Stack Overflow page you linked, piCookie quotes the C standard, section 6.10.2, which states:

* A preprocessing directive of the form

#include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a header identified 
uniquely by the specified sequence between the < and > delimiters, and causes 
the replacement of that directive by the entire contents of the header. How the 
places are specified or the header identified is implementation-defined.

I read that to say that the angle brackets are also implementation specific, so I don't think switching to angle brackets solves the theoretical security concern. Since the compiler is free to do what it wants, there is no way for the authors of libplist to guarantee that the correct headers are included. Furthermore, on the same page user ydroneaud points out that the POSIX c99 standard does specify that searches for quoted files should search the current directory first.

from libplist.

Both inclusion approaches were specified as to be implementation-defined.

Since the compiler is free to do what it wants, there is no way for the authors of libplist to guarantee that the correct headers are included.

What would happen if you would choose to omit the quotation include for software library header files (because of the view that angle brackets includes might be more appropriate)?

from libplist.

@aburgh that's a word. Closing.

from libplist.