Use of angle brackets around file names for include statements

[elfring]

Would you like to replace any double quotes by angle brackets around file names for include statements?

[bagder]

Why? We use double quotes for local include files, why should we not?

[elfring]

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?

[bagder]

This is not C++.

This code has been built on a huge amount of platforms and operating systems already. Do you have a specific problem you want to address?

How do you think about to avoid “a duplicated file search” here?

I don't understand what that refers to.

Would you like to restrict the searched directories for header files of your software?

I don't understand what this refers to either. Again: when we want to include a local header file, why should we not check for it in the local directory first?

[elfring]

• How do you think about to avoid potential confusion around the wording “local (or current) directory”?
• Do you expect that (header) files for such a software library will be used from a storage location where they were installed?

---

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”?

[bagder]

This is an issue tracker.

Do you have a specific problem with the include files?

[elfring]

I am trying to achieve that the needed files are actually retrieved from trusted directories according to preferred software build parameters.
How much will the selected file inclusion style matter then?

[bagder]

I am trying to achieve that the needed files are actually retrieved from trusted directories

Are you building curl/libcurl with something else than one of the shipped build mathods and this method has a problem with C source files using include files within double quotes? What method/compiler/setup is this?

[elfring]

I suggest to take another look at the following difference.

…
#include <curl/curl.h>
…
#include "curl_sspi.h"
…

[bagder]

I suggest to take another look at the following difference.

I looked. I see no problem. Do you?

[jzakrzewski]

@bagder I don't get this guy. He opens basically the same issues in various repositories. Everyone tells him "no" for more or less the same reasons you have stated and he just keeps going. The argumentation is basically a copy-paste.

The conclusion from one of the threads ( json-c/json-c#440 ) was that he's a carbon-based bot ;)

[elfring]

• From which storage location should a library file be picked up preferably?
  • Known installation directory
  • Random (or temporary) software development status
• Do inclusion specifications for files like “curl.h” and “curl_sspi.h” refer to the same library version?

[bagder]

"curl.h” should never be included. We suggest <curl/curl.h> for applications since the header is supposed to be included from the system include path.

curl_sspi.h is a private header file that only libcurl uses when you build it, which is why it is included with double quotes. This is never included by applications.

[elfring]

We suggest <curl/curl.h> for applications since the header is supposed to be included from the system include path.

Can this expectation fit to any more inclusion specifications of other software components?

curl_sspi.h is a private header file that only libcurl uses when you build it, which is why it is included with double quotes.

How “private” is such a header file during the mentioned software build process?

This is never included by applications.

Would you like to increase the distinction for the safe reuse of software components there and at other stages of programming?

[bagder]

Can this expectation fit to any more inclusion specifications of other software components?

Other libraries have their headers and defined use.

How “private” is such a header file during the mentioned software build process?

Entirely private.

Would you like to increase the distinction for the safe reuse of software components there and at other stages of programming?

What are you talking about?

I now conclude that you do not experience an issue with the include files, and therefore I close this issue.