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?

[hawicz]

For #include "filename" the preprocessor searches first in the same directory as the file containing the directive, ...

and the files included by json.h are meant to be those which are locate in the same directory so, no, we will not replace those with angle brackets.

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

[hawicz]

You're not making any sense. How do you end up with a "duplicated file search" when the headers are in the same directory, and thus will be found immediately?
Why would we want to restrict the searched directories to just system directories when the files are, again, in the same directory ?

[elfring]

I suggest to take another look at the situation for an application programmer.
The required header files will be installed in a known directory.

• Do you expect then that the desired header files are usually not found in the source directory which is used by the programmer?
• Should headers be directly retrieved from a trusted include directory (without a lookup attempt from an other storage location)?

I prefer to avoid possible misunderstandings around the wording “the same directory”.

[ploxiln]

In this case, json.h contains #include "debug.h" so it will look in the same directory as json.h and it will find the correct file. The name "debug.h" is somewhat generic and at risk of also being used by a header from a different library or program, so doing #include <debug.h> would definitely be worse because it might find the wrong file, while #include "debug.h" will definitely find the correct file.

I think the ultimate answers to your pointed questions is that you will not be comfortable using libevent and should find an alternative.

[elfring]

The statement “#include <json-c/debug.h>” could be specified instead, couldn't it?

[hawicz]

No, because that will pick up /usr/include/json-c/debug.h, even if I am attempting to compile against, for instance, a copy I've installed to /home/erh/json-c-current/ and it should be including /home/erh/json-c-current/include/json-c/debug.h.
Using angle brackets for these includes is just plain wrong.

[elfring]

• How do you think about to reduce the probability for name clashes any further?
• Would you like to adjust any build parameters for software applications?

[rgerhards]

mmmhhh.. while @elfring is doing some nit-picking, the argument is not that weak. But @hawicz is also right in regard to developing json-c or having a special version on the system that is not installed into the default locations (but that could be handled via ./configure --prefix, --includedir, etc). It's primarily an issue for json-c developers themselves.

How about adding a configure switch (--enable-system-includes) which could selectively use one form or the other?

[hawicz]

What argument? That we abandon a proven working method for ensuring the right header files are included, and instead switch to something that is dependent on getting the build parameters for anything that uses json-c just right? No thank you, not even as a configure switch, especially since that would be building some kind of terrible hack to generate the header files.

If there's a clash between the file names that json-c uses for it's headers and those located elsewhere, then feel free to do something like rename "debug.h" to "json_c_debug,h", but that's not at all what is being suggested in this bug report.

[elfring]

• Build parameters are always involved, aren't they?
• Where do you find a renaming acceptable?
  • File
  • Directory

[rgerhards]

Just in case you were also curios. I did some background checks on elfring: it's highly probable a bot. Just one reference: https://twitter.com/johnregehr/status/718832080118005760 - also a look at the user profile might be helpful.

[elfring]

I suggest to recheck the available public development statistics.

[ploxiln]

Clearly not a bot, I think; just a very unusual individual.

[rgerhards]

Well, in a sense it doesn't matter if it is carbon or silicone based - it acts like a bot. Nough said ;-) Sent from phone, thus brief. Pierce Lopez <notifications@github.com> schrieb am So., 29. Juli 2018, 18:23:

…

Clearly not a bot, I think; just a very unusual individual. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#440 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABadi2skAOniN-A3lAy58unJs5STzBdeks5uLeGZgaJpZM4ViP5A> .