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

[CBFalconer]

rb********@mailinator.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>

[MQ]

rb********@mailinator.com wrote:

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]

rb********@mailinator.com writes:

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.

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

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

--
Keith Thompson (The_Other_Keith) 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.

[Brian C]

rb********@mailinator.com wrote:

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]

rb********@mailinator.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.

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
es*****@acm-dot-org.invalid

[Eric Sosman]

MQ wrote:

rb********@mailinator.com wrote:

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

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.

;-)

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

[Kenny McCormack]

In article <11**********************@73g2000cwn.googlegroups. com>,
MQ <mi**************@gmail.comwrote:

>
rb********@mailinator.com wrote:

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

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:
<snip>

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 =)
--
WYCIWYG - what you C is what you get

[rbhlgjwbvi]

Eric Sosman wrote:

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)

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]

Eric Sosman wrote:

>
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]

rb********@mailinator.com said:

<snip>

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Richard Heathfield wrote:

rb********@mailinator.com said:

<snip>

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

In addition copies of the C99 standard are readily available, which
does not apply to the C90 standard.

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

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>rb********@mailinator.com said:

<snip>

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

In addition copies of the C99 standard are readily available, which
does not apply to the C90 standard.

True (although you can get a C89 draft easily enough). But there's no great
advantage to having easy accessibility to a standard that hardly anyone has
implemented.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Mark McIntyre]

On Mon, 04 Dec 2006 07:48:25 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:

>But there's no great
advantage to having easy accessibility to a standard that hardly anyone has
implemented.

Other, of course, than making sure your code is as future-proof as can
be reasonably expected.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Heathfield]

Mark McIntyre said:

On Mon, 04 Dec 2006 07:48:25 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:

>>But there's no great
advantage to having easy accessibility to a standard that hardly anyone
has implemented.

Other, of course, than making sure your code is as future-proof as can
be reasonably expected.

Good spot. Yes, okay, that's true. But *apart* from that, what have the
Romans ever done for us, eh?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Mark McIntyre wrote:

Richard Heathfield <rj*@see.sig.invalidwrote:

>But there's no great advantage to having easy accessibility to a
standard that hardly anyone has implemented.

Other, of course, than making sure your code is as future-proof as
can be reasonably expected.

This is one of the few times I have to agree with Mark over
Richard. :-)

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

[Eric Sosman]

rb********@mailinator.com wrote:

Eric Sosman wrote:

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

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

There are some things in C99 whose usefulness eludes me,
but face it: ISO/IEC 9899:1999 (as amended) is the International
Standard. "Be not the first by whom the new is tried, nor yet
the last to lay the old aside."

As for the characters permitted in header names: The rule
is not new, not some kind of C99 invention. You will find the
same rule in Section 3.1.7 of the ANSI C Standard, vintage 1989.

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

[CBFalconer]

Richard Heathfield wrote:

Mark McIntyre said:

>Richard Heathfield <rj*@see.sig.invalidwrote:

>>But there's no great advantage to having easy accessibility to
a standard that hardly anyone has implemented.

Other, of course, than making sure your code is as future-proof
as can be reasonably expected.

Good spot. Yes, okay, that's true. But *apart* from that, what
have the Romans ever done for us, eh?

Aren't you guys still using their baths, roads, and walls?

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

[pete]

Eric Sosman wrote:

>
rb********@mailinator.com wrote:

Eric Sosman wrote:

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

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

There are some things in C99 whose usefulness eludes me,
but face it: ISO/IEC 9899:1999 (as amended) is the International
Standard. "Be not the first by whom the new is tried, nor yet
the last to lay the old aside."

As for the characters permitted in header names: The rule
is not new, not some kind of C99 invention. You will find the
same rule in Section 3.1.7 of the ANSI C Standard, vintage 1989.

Header names are in 6.1.7 in my copy of ISO/IEC 9899: 1990.

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Eric Sosman wrote:

[...]

> As for the characters permitted in header names: The rule
is not new, not some kind of C99 invention. You will find the
same rule in Section 3.1.7 of the ANSI C Standard, vintage 1989.

Header names are in 6.1.7 in my copy of ISO/IEC 9899: 1990.

Yes, one of the few differences between the 1989 ANSi standard and the
1990 ISO standard is that the latter adds some sections (or splits up
some existing sections?) in accordance with ISO rules. I think that
ANSI C89 3.X.Y always corresonds to ISO C90 6.X.Y, and it's probably
the same for 4 vs. 7.

(I don't think I've ever seen a copy of the actual 1989 ANSI C
standard. ANSI adopted the ISO standard shortly after it was issued;
presumably they stopped printing the older version at that time.)

--
Keith Thompson (The_Other_Keith) 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.

[Mark McIntyre]

On Mon, 04 Dec 2006 08:05:26 -0500, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>Richard Heathfield wrote:

>Mark McIntyre said:

>>Richard Heathfield <rj*@see.sig.invalidwrote:

But there's no great advantage to having easy accessibility to
a standard that hardly anyone has implemented.

Other, of course, than making sure your code is as future-proof
as can be reasonably expected.

Good spot. Yes, okay, that's true. But *apart* from that, what
have the Romans ever done for us, eh?

Aren't you guys still using their baths, roads, and walls?

er...

romani eunt domi.?
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Eric Sosman]

pete wrote:

Eric Sosman wrote:

>rb********@mailinator.com wrote:

>>Eric Sosman wrote:
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)
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 :)

There are some things in C99 whose usefulness eludes me,
but face it: ISO/IEC 9899:1999 (as amended) is the International
Standard. "Be not the first by whom the new is tried, nor yet
the last to lay the old aside."

As for the characters permitted in header names: The rule
is not new, not some kind of C99 invention. You will find the
same rule in Section 3.1.7 of the ANSI C Standard, vintage 1989.

Header names are in 6.1.7 in my copy of ISO/IEC 9899: 1990.

I see now - "the Standard" seems to mean "the C90 standard"
in these parts, rather than ANSI. Slightly depressing that such
a monstrosity has gained such currency - ANSI was a thing of beauty,
essentially perfect, and the idea of wantonly renumbering all its
exquisite paragraphs and throwing out its non-normative elucidations
is not a pleasing one.

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

[Richard Bos]

rb********@mailinator.com wrote:

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!

Not at all. The implementation _shall_ provide mappings for any
ABCDEFGH.I style header name, but it _may_ accept any other name it
likes. And implementations commonly do. What it does mean is that
#include </this/is/a/path/header.his not portable; but that should be
no surprise, because path names themselves are not portable. Would you
expect #include <C:\Program Files\Woggo-C\Projects\Program\header.hto
work on a unixoid? Of course not. And similarly, a path starting with /
is not valid on a system which uses another directory separator. Your
unixy cc may accept it, but there's no reason for a mainframe compiler
to do so.

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.

As a sysadmin as well as a programmer, my sincere reaction is: bleurgh.
Please stop messing with my directory listings. Fix your script, don't
spay your directories.

Richard