[comp.std.c] strange filenames in __FILE__ macro

lai@mips.COM (David Lai) (08/25/89)

Does the standard specify what characters are legal for a filename.
Specifically, when the __FILE__ macro is expanded, does the preprocessor
have to perform special excape sequence translations.

As an example, in MS-DOS systems the '\' character is prevalent in pathnames,
does each '\' in the pathname get translated to '\\' when expanding __FILE__?

How about filenames with '"' or "'" or non-printing characters?
-- 
        "What is a DJ if he can't scratch?"  - Uncle Jamms Army
     David Lai (lai@mips.com || {ames,prls,pyramid,decwrl}!mips!lai)

dfp@cbnewsl.ATT.COM (david.f.prosser) (08/29/89)

In article <26208@gumby.mips.COM> lai@mips.COM (David Lai) writes:
>Does the standard specify what characters are legal for a filename.
>Specifically, when the __FILE__ macro is expanded, does the preprocessor
>have to perform special excape sequence translations.
>
>As an example, in MS-DOS systems the '\' character is prevalent in pathnames,
>does each '\' in the pathname get translated to '\\' when expanding __FILE__?
>
>How about filenames with '"' or "'" or non-printing characters?

__FILE__ must be replaced with a valid character string literal.  Since
#include "..." is not necessarily a valid character string literal, and
since these two are most likely related (in a "quality" implementation),
the presumption is that the implementation should produce a string
literal that, when printed at runtime, will "look like" the name of the
source file.  Thus troublesome characters like backslash, new-line,
double-quote, etc. should be generated by escape sequences.

Of course this is all a "quality of implementation" issue: the presumed
name of the source file could always be "stdin" or ""!

Dave Prosser	...not an official X3J11 answer...