Use of . within header file names.
- Thread starter ApacheKid
- Start date
Are you talking about restrictions on syntax or semantics?
Well it works here but wanted to know if it was like implementation based, like some compilers handle it others don't, that's really what I'm seeking.
I see no problem with this, it works here:
Well, I don't think "periods are a problem in a quoted string" Mr. Bravo. My question aims to gather input from others as to whether such a practice might be reliant on implementations. For all I know some implementations might expect strictly <text.suffix> or "text.suffix" and tolerate no additional dots in the name.
I'm just doing due diligence!
AFAIK, Mr. Kid, the compiler does not care about the characters inside the quotes, or the angle brackets of an #include directive, it simply passes the information contained between the delimiters to the OS file system. The OS file system may or may not have a problem with the contents of the string depending on which OS is receiving the string and which version of that OS is present, neither of which you cared to specify. If it does have a problem, it will surely cause the compiler to throw an error when it tries to open the file. Also consider that if the OS allowed the file to be created and displayed with that name it stands to reason that it would allow you to open the file to be included in the compilation process.
When asking for help you might want to consider a gentler attitude.
That doesn't tell me whether you are asking about restrictions on the syntax, or restrictions on the semantics.
SYNTAX:
If angle-brackets are used as delimiters, then any character from the source character set can be used between them except a new line character and a right-angle-bracket.
If double-quotes are used as delimiters, then any character from the source character set can be used between them except a new line character and a double-quote.
SEMANTICS:
Header names are mapped to standard header files or external source file names in an implementation defined manner subject to certain constraints.
If the characters in the set {', \, ", \, //, /*} appear between the delimiters, the behavior is undefined -- thus character sequences that resemble escape sequences invoke undefined behavior.
It is NOT a quoted string. It is a "header name preprocessing token" (which can only exist in a #include preprocessing directive).
The rules for each are different.
For instance:
#include "..\the_headers\new_header.h"
This invoked undefined-behavior because of the presence of the '\' characters. If this were just a quoted string, it would result in a string containing a tab character and a new-line character (the latter of which would be a violating of the syntax rules).
However, MOST compiler implementations will allow sequences that follow the normal rules for filepath specifications on that platform (but they are not required to).
Furthermore, it can contain preprocessing tokens that are processed to form a header name preprocessing token (in an implementation-defined manner), whereas if it were a quoted string the characters that define the preprocessing tokens would simply be treated as part of the literal string.
Why don't you just read the language specification?
While you have to pay to get the final specifications (though it's something like $30, so not outrageous), the final publicly-released draft specification (which is essentially identical except for some administrative and editorial content, though there ARE differences) is N869.txt for C99 and N1570.txt for C11. Both are widely available on the Internet.
I keep meaning to buy the actual standards, but never get around to it.
This is at odds with your earlier reply, where you said it was a quoted string. If it's just passing the information to the OS, then it can't be treating it as a quoted string (which involves such things as the substitution of escape sequences contained within it).
It doesn't just simply pass it too the OS. How would the OS know where to look for the standard header files? Also, if the implementation fails to find the file with a #include that uses double quotes, it is required to attempt to find it as if angle-brackets were used instead.
In addition, the header name between delimiters can contain other preprocessing tokens that are processed to construct a file name, though whether this is actually allowed is implementation dependent (preprocessing tokens that build the header name, to include the delimiters, are required to be processed if they are NOT contained between delimiters).
It depends on the Preprocessor. Some header file names might be mangled into compatible OS file names like 8.3 file names on old DOS/Windows based compiler systems.
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/cppinternals/Files.html#Files
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/cppinternals/Files.html#Files
The #include preprocessor directive allows the use of double quotes or angle brackets. The choice has to do with where the compiler might expect to find those include files. The treatment is implementation dependent, but generally, the quotes prioritize files in the current working directory while the angle brackets are for other system directories.
I must admit it would be interesting to see how escape sequences are treated in a #include directive.
I must admit it would be interesting to see how escape sequences are treated in a #include directive.
I did read several sources before posting my question, others have asked about this:
Examples:
https://stackoverflow.com/questions/34692366/c-is-it-legal-to-use-dot-dot-in-include-directive
specifically look at this image from there:
Anyway, it works so I have my answer, thank you all for your kind assistance.
How escape sequences are treated is undefined behavior, so the implementation is completely free to do whatever it wants to. On most compilers I have used, they aren't recognized at all, primarily because the backslash is used as a filepath separator on DOS/Windows machines. Having said that, some of them do play games with them because they apparently recognize that programmers are likely to escape the backslashes the way they would in a string literal. On my current install (Embacadero, which is using TDM-GCC 9.2.0), consecutive backslashes appear to be reduced to a single backslash. Who knows what other things they do -- it may be documented somewhere, but since it is undefined behavior, there is no documentation requirement.
Just keep in mind that it works they way you want it to on this version of the compiler you are currently using.
Talking of backslashes and stuff, I fondly recall the VOS operating system developed by Stratus for their fault tolerant minicomputers in 1980. They had the good sense to adopt the Multics convention and abandon the silly Unix and Windows approaches.
On VOS (like Multics), pathnames used < and > to indicate "up" and "down" the directory hierarchy, nothing could be simpler. Device names like network adapters or disks had # prefixed names, so here's what pathnames looked like:
#d01>logs>production>tuesday_11_19.log
If one was logged in interactively and situated in a folder #d02>Projects>Datafeeds>Services>Reuters for example and wanted to move up to the Datafeeds directory, we'd simply type:
ccd <<
or to go up then down perhaps, we'd type:
ccd <<Configuration>Testing
which would put is in the #d02>Projects>Datafeeds>Configuration>Testing directory.
So simple, so symmetrical, why the Unix guys opted for slashes and dots, I'll never understand.
On VOS (like Multics), pathnames used < and > to indicate "up" and "down" the directory hierarchy, nothing could be simpler. Device names like network adapters or disks had # prefixed names, so here's what pathnames looked like:
#d01>logs>production>tuesday_11_19.log
If one was logged in interactively and situated in a folder #d02>Projects>Datafeeds>Services>Reuters for example and wanted to move up to the Datafeeds directory, we'd simply type:
ccd <<
or to go up then down perhaps, we'd type:
ccd <<Configuration>Testing
which would put is in the #d02>Projects>Datafeeds>Configuration>Testing directory.
So simple, so symmetrical, why the Unix guys opted for slashes and dots, I'll never understand.
Last edited:
