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)

[Eric Sosman]

pete wrote:

Eric Sosman wrote:

>rb********@mail inator.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 "Programmin g 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********@mail inator.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\Prog ram\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
"projectnam e
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