Are you talking about restrictions on syntax or semantics?It seems there's no prohibition on file names containing multiple periods in C, e.g.
Is anyone here aware of any restrictions?Code:#include "nrf_hal_support.externs.h"
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 not sure I understand why you think periods are a problem within a quoted string. You seem to be imagining a major malfunction.
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.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!
That doesn't tell me whether you are asking about restrictions on the syntax, or restrictions on the 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:
It is NOT a quoted string. It is a "header name preprocessing token" (which can only exist in a #include preprocessing directive).I not sure I understand why you think periods are a problem within a quoted string. You seem to be imagining a major malfunction.
Why don't you just read the language specification?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!
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).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.
I did read several sources before posting my question, others have asked about this:Why don't you just read the language specification?
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.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.
Just keep in mind that it works they way you want it to on this version of the compiler you are currently using.Anyway, it works so I have my answer, thank you all for your kind assistance.
by Duane Benson
by Jake Hertz
by Aaron Carman