Header file names

[rbhlgjwbvi]

I have a header whose filename contains an embedded newline and I can't
seem to #include it successfully. I've tried

#include "my
file.h"

and

#include "my\nfile.h "

but neither works.

1. How can I achieve this?
2. Does the Standard limit the range of characters that can appear in
source file names? (for example, embedded tabs seem to be fine with an
actual tab character in the #include line)

[Ian Collins]

rb********@mail inator.com wrote:

I have a header whose filename contains an embedded newline and I can't
seem to #include it successfully. I've tried

So don't do it.

--
Ian Collins.

[rbhlgjwbvi]

Well, that would be one solution... but it's not ideal - I'd like to
arrange my files according to my preferred conventions.

I think that #include "...\n..." doesn't work because the thing isn't a
string literal, but is interpreted by the preprocessor.

I really don't see why the preprocessor doesn't read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc's implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

Ian Collins wrote:

rb********@mail inator.com wrote:

I have a header whose filename contains an embedded newline and I can't
seem to #include it successfully. I've tried

So don't do it.

--
Ian Collins.

[Eric Sosman]

chunks of the compiler that cares about line boundaries.
the preprocessor is line-oriented; it is one of the few
Section 6.4.7 paragraph 1. The likely reason is that
are forbidden in header names, as you will find in
Newlines

and also illustrates why top-posting is unpopular.
I hope this answer satisfies your curiosity,

rb********@mail inator.com wrote:

Well, that would be one solution... but it's not ideal - I'd like to
arrange my files according to my preferred conventions.

I think that #include "...\n..." doesn't work because the thing isn't a
string literal, but is interpreted by the preprocessor.

I really don't see why the preprocessor doesn't read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc's implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

Ian Collins wrote:

>rb********@mail inator.com wrote:

>>I have a header whose filename contains an embedded newline and I can't
seem to #include it successfully. I've tried

So don't do it.

--
Ian Collins.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Keith Thompson]

rb********@mail inator.com writes:

I have a header whose filename contains an embedded newline and I can't
seem to #include it successfully. I've tried

#include "my
file.h"

and

#include "my\nfile.h "

but neither works.

1. How can I achieve this?
2. Does the Standard limit the range of characters that can appear in
source file names? (for example, embedded tabs seem to be fine with an
actual tab character in the #include line)

For a directive of the form
#include "..."

the standard merely says that the sequence of characters between the
quotation marks (it's not really a string literal, though it looks
like one) "identifies " some source file. The manner in which it does
so is implementation-specific. Furthermore (C99 6.10.2p5):

The implementation shall provide unique mappings for sequences
consisting of one or more letters or digits (as defined in 5.2.1)
followed by a period (.) and a single letter. The first character
shall be a letter. The implementation may ignore the distinctions
of alphabetical case and restrict the mapping to eight significant
characters before the period.

There is no guarantee that all files can be specified by a #include
directive. In particular, I wouldn't be at all surprised if it were
impossible to refer to a file whose name contains a newline.

Why in the name of sanity would you want to have a header file with a
newline in its name in the first place?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

rb********@mail inator.com writes:

I really don't see why the preprocessor doesn't read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc's implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

The Standard does allow compilers to interpret file names in
#include differently from string literals. One reason is that
some systems use backslash as a common character in file names.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein

[Keith Thompson]

rb********@mail inator.com writes:

Well, that would be one solution... but it's not ideal - I'd like to
arrange my files according to my preferred conventions.

I think that #include "...\n..." doesn't work because the thing isn't a
string literal, but is interpreted by the preprocessor.

I really don't see why the preprocessor doesn't read a ", then look for
a closing ", then interpret everything in between (newlines or not) as
the filename. Is this just a problem with gcc's implementation, or does
the Standard actually allow compilers to place artifical restrictions
on the characters allowed in source file names? If so, why?

Please don't top-post. Read the following:

http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

I've never even seen a file name with an embedded newline, except
perhaps one created by accident or to prove a point. Yes, compilers
are allowed to place artificial restrictions on the characters allowed
in source file names. See my other followup for more details.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[rbhlgjwbvi]

Eric Sosman wrote:

chunks of the compiler that cares about line boundaries.
the preprocessor is line-oriented; it is one of the few
Section 6.4.7 paragraph 1. The likely reason is that
are forbidden in header names, as you will find in
Newlines

That reference seems to be broken - there's no subsection 6.4.7, and
section 6.4, "constant expressions", doesn't mention headers.

and also illustrates why top-posting is unpopular.
I hope this answer satisfies your curiosity,

Top-posting is nowhere near as confusing as rearranging the lines of
your message. I find it quite common (even the norm) in most email
conversations.

[rbhlgjwbvi]

Keith Thompson wrote:

For a directive of the form
#include "..."

the standard merely says that the sequence of characters between the
quotation marks (it's not really a string literal, though it looks
like one) "identifies " some source file. The manner in which it does
so is implementation-specific.

Hmm, maybe I should file a bug/wishlist against gcc then.

Furthermore (C99 6.10.2p5):

The implementation shall provide unique mappings for sequences
consisting of one or more letters or digits (as defined in 5.2.1)
followed by a period (.) and a single letter. The first character
shall be a letter. The implementation may ignore the distinctions
of alphabetical case and restrict the mapping to eight significant
characters before the period.

That would seem to suggest it's impossible to directly give an absolute
path to a header file, which would start with / rather than a letter,
without using a command-line flag to the compiler or an environment
variable - odd! (For ref, I prefer the C90 standard - C99 seems like a
bit of a lame duck to me.)

Why in the name of sanity would you want to have a header file with a
newline in its name in the first place?

I have some legacy scripts for processing ls output that rely on
filenames being in the form
"projectnam e
filename"
I think that's quite a clear layout in any case.

[CBFalconer]

rb********@mail inator.com wrote:

Eric Sosman wrote:

chunks of the compiler that cares about line boundaries.
the preprocessor is line-oriented; it is one of the few
Section 6.4.7 paragraph 1. The likely reason is that
are forbidden in header names, as you will find in
Newlines

That reference seems to be broken - there's no subsection 6.4.7, and
section 6.4, "constant expressions", doesn't mention headers.

6.4 Lexical elements
....
6.4.7 Header names

>

>and also illustrates why top-posting is unpopular.
I hope this answer satisfies your curiosity,

Top-posting is nowhere near as confusing as rearranging the lines of
your message. I find it quite common (even the norm) in most email
conversations.

Most users of e-mail are ignorant slaves to Outhouse Excess.
However, ignorance is curable.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>