Back slashes in #include.

[Control Freq]

Hi,
Apologies if this has been discussed before.

I have inherited a large body of code which has served well for many
years in various projects.

Now, i need to use some of it in a Linux environment, compiling with
GCC.

I notice that some of the #include statements use DOS style
backslashes, and GCC complains with an error.
There are no options for GCC to be forgiving in these circumstances.

I notice that this code has compiled for years in a DOS/Windows
environment with several different toolchains.

My K+R book says that the use of back slashes in #include statements
are un-defined.

So, Should I go ahead and change the backslahes to unix style forward
slashes?
Will it break any other compiler tool chains?


Thanks in advance.

Nick

 

[Ian Collins]

Hi,
Apologies if this has been discussed before.

I have inherited a large body of code which has served well for many
years in various projects.

Now, i need to use some of it in a Linux environment, compiling with
GCC.

I notice that some of the #include statements use DOS style
backslashes, and GCC complains with an error.
There are no options for GCC to be forgiving in these circumstances.

I notice that this code has compiled for years in a DOS/Windows
environment with several different toolchains.

My K+R book says that the use of back slashes in #include statements
are un-defined.

So, Should I go ahead and change the backslahes to unix style forward
slashes?
Probably.

Will it break any other compiler tool chains?

Probably not! Windows tools are generally tolerant of Unix line endings
as well, while Unix tool can be less than tolerant of DOS line endings.

 

[robertwessel2]

Hi,
Apologies if this has been discussed before.

I have inherited a large body of code which has served well for many
years in various projects.

Now, i need to use some of it in a Linux environment, compiling with
GCC.

I notice that some of the #include statements use DOS style
backslashes, and GCC complains with an error.
There are no options for GCC to be forgiving in these circumstances.

I notice that this code has compiled for years in a DOS/Windows
environment with several different toolchains.

My K+R book says that the use of back slashes in #include statements
are un-defined.

Actually so are forward slashes - basically the entire content of the
file name string on the include is implementation defined, except that
it needs to support filenames consisting of 8 characters plus a dot
plus a single character (with a very restricted character set).

So, Should I go ahead and change the backslahes to unix style forward
slashes?
Will it break any other compiler tool chains?

Most DOS/Windows C compilers will accept both forward and back slashes
as directory delimiters. You'd need to check the documentation of
your specific compiler to see what it accepts.

 

[Keith Thompson]

Use forward slashes for directory path delimiters at all times in your
source. The MS compilers will accept it and GCC will be happy.

Another issue is that the interpretation of '\' characters in header
names is implementation-defined.

For example, in a string literal:

"foo\bar.h"

a \b sequence denotes a backspace character. But a header name:

#include "foo\bar.h"

is not syntactically a string literal. Some compilers might treat
the \b as a backspace, some might treat it as a backslash character
followed by the letter 'b'. (I don't know what MS compilers do.)

Using '/' rather than '\' in file names is another issue.
It's often been pointed out here that MS-DOS and Windows accept
'/' as a directory delimiter, but '\' is the "normal" delimiter.
If you're going to be showing file names to the user, it's arguably
better to use '\' to match the user's expectations. And if you write
your code flexibly enough to handle different delimiters, it has a
better chance of working on systems that don't use either '/' or '\'.

Somebody mentioned that VMS compilers accept '/' in #include
directives. I wouldn't count on similar behavior for fopen().