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]

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.

 

[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

 

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

 

[Ben Pfaff]

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.

 

[Keith Thompson]

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]

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.

 

[rbhlgjwbvi]

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]

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
"projectname
filename"
I think that's quite a clear layout in any case.

 

[CBFalconer]

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

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.

 

[MQ]

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

Why on Earth would you want to persist with such an abomination? What
advantage is there to having a filename with an embedded newline?

MQ

 

[Keith Thompson]

Keith Thompson wrote: [...]

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.)

Not at all. It suggests that it's impossible to *portably* give an
absolute path. All implementations must support the limited form of
header names described in 6.10.2p5; most implementations support much
more than that.

An implementation for a system that doesn't use '/' as a directory
delimiter, for example, might not allow '/' in header names -- or it
might allow them and translate them to some system-specific form.

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

Hmm. Personally I find that horrifying, but if it works for you
that's fine, and some systems do permit it.

 

[Brian C]

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)

Rename it?

 

[Eric Sosman]

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

ISO/IEC 9899:1999 "Programming Languages -- C"
Section 6 "Language"
Section 6.4 "Lexical elements"
Section 6.4.7 "Header names"
Paragraph 1 (syntax description)

Appears on page number 64 (happy coincidence?), the 78th
page image in the document.

 

[Eric Sosman]

Why on Earth would you want to persist with such an abomination? What
advantage is there to having a filename with an embedded newline?

Hmmm... Perhaps it's not the "name" of the file, but
of a "directory" somewhere on its "path?"

X:\My Pet Projects\It was the best of times,
it was the worst of times, it was the age of
foolishness, it was the epoch of belief, it
was the epoch of incredulity\Cstuff\header.h

If the long directory name were not broken into multiple
lines with embedded newline characters, it might be found
unwieldy.

;-)

 

[Kenny McCormack]

Why on Earth would you want to persist with such an abomination? What
advantage is there to having a filename with an embedded newline?

While it is hard for you or me to imagine that this actually happened in
real life, you do pretty much have to take OP's word for it that it did.

Basically, the answer is: because that's the file's name.

Note the progression of "weird filenames" (the first part is taken from
the DOS/Windows world - may not be directly applicable to Unix or other
platforms):
1) In the beginning, there was 8.3 (and that was Good)
2) Then there was "long filenames".
3) Then there were filenames with embedded spaces and other
"funny" characters (like ' or ")
4) Then there were filenames with embedded newlines, etc.

The point is that, if you have a filesystem that allows this sort of
stuff, then the rest of your apparatus should support it. To not do so
is to invite disaster.

 

[matevzb]

Keith Thompson wrote:

I've never even seen a file name with an embedded newline, except
perhaps one created by accident or to prove a point.

Well I have, many-a-time. Not only that, but since (as far as I know)
un*x-ish systems allow anything but / and NUL characters in a filename,
I had the "pleasure" to see *s, ?s and whatnot in a filename, often
with problematic outcome - a file called "-rf" and shell expansion when
doing a "rm *" can do magic.

Don't underestimate the ignorance of software users =)

 

[rbhlgjwbvi]

ISO/IEC 9899:1999 "Programming Languages -- C"
Section 6 "Language"
Section 6.4 "Lexical elements"
Section 6.4.7 "Header names"
Paragraph 1 (syntax description)

I see now - "the Standard" seems to mean "the C99 standard" in these
parts, rather than C90. Slightly depressing that such a monstrosity has
gained such currency - C90 was a thing of beauty, essentially perfect,
and the idea of polluting something so pure with // comments,
variable-length arrays and all the other junk is not a pleasing one

 

[MQ]

If the long directory name were not broken into multiple
lines with embedded newline characters, it might be found
unwieldy.

In which case you would have to ponder the purpose of having such long
directory names. And I have seen some awful filenames at a company I
worked at, who seemed to abuse the filename size limit just because
they could. For example, files like "Client - XXX, Job - YYY, Meeting
regarding ZZZ, 24th July 2003.doc". This from a customer service
consultant who didn't know how to create directories, or spell the word
"staple" (she spelt it "staibel"). I remember reading job notes and
wetting myself laughing at her spelling and grammar which in some cases
was so bad as to look like some sort of pidgin language.

MQ

 

[Richard Heathfield]

(e-mail address removed) said:

I see now - "the Standard" seems to mean "the C99 standard" in these
parts, rather than C90.

It depends who you talk to. IMHO, yes, okay, C99 is the de jure standard,
but C90 remains the de facto standard for the time being, because hardly
any conforming C99 implementations exist. C99 effectively standardises
vapourware.