1

I gave a project that should be compiled under the GNU/Linux. As you perhaps guessed already, all the headers in the project use the backslash symbol \.

I know, the backslash is undefined behavior, but I need to compile it. I am pretty sure that there is a way to make GCC work with this, as the MinGW version works fine with the backslashes (I just checked this).

The most funniest thing is that the project is an application for GNU/Linux (for the ARM architecture), and likely the ARM GCC works just fine. I am just the only guy who uses GNU/Linux natively and wanted to compile the application for a desktop to have an easier debug life.

Replace the backslashes to slashes and force the colleagues to relearn for using other characters is not the way: I am just a junior, but a colleague who has worked here 4-7 years already; they just won't hear me. So, here we go...

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Hi-Angel
  • 4,933
  • 8
  • 63
  • 86

4 Answers4

5

Replace the backslashes with slashes. Tell your colleagues to look at this Stack Overflow post.

I've been writing C code for over 24 years. Backslashes are just plain WRONG. If it mattered (which, in point of fact, it doesn't, since Windows is happy to use forward slashes as a path separator if presented with them), it would be up to the C compiler to transform them.

al45tair
  • 4,405
  • 23
  • 30
4

You probably mean backslash in #include preprocessor directives, related to file names.

And we all know that it is wrong to use backslash in #include-d paths

There is AFAIK no easy way to transform them magically into ordinary (division) slashs, since most of the #include processing is about querying the host operating system file system (thru fopen(3) calling open(2) etc....)

(if you have lot of time to lose, you might consider dirty LD_PRELOAD tricks overloading fopen etc... I don't recommend doing that)

You could more simply use sed(1) to change (e.g. in your Makefile, or perhaps in your own $HOME/bin/gcc script invoking the real /usr/bin/gcc, with a suitable $PATH....) the backslashes when they appear in a #include line (only in such lines).

Look inside GCC source code, it is free software, notably file libcpp/directives.c (which handles preprocessor directives); feel free to patch it for your bizarre needs, and publish your patch somewhere!

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • There is a way to make the GCC consider a backslashes as the forward slashes. I know, because, the project was compiled for ARM via GCC. And the MinGW GCC consider the backslashes as an ordinary slashes too. – Hi-Angel Jul 10 '14 at 10:57
  • 3
    MinGW is running on a Microsoft system whose filesystem code handles the backslash. And your ARM cross-compiler is probably running on Microsoft also... I'm sure an ARM cross-compiler hosted on Linux will be unhappy with backslashes in `#include` – Basile Starynkevitch Jul 10 '14 at 10:59
  • Using a *fake* GCC is a great hacky idea! This is seems to be the way, because in this project not the makefile, but a CodeBlocks project. Though I never worked with the `sed` yet, so I will accept this answer after I finally get it to work -- in order for the answer to have a working solution for anyone, who googled here. But I like the @alastair 's answer as well, I'll tell about it to colleagues. – Hi-Angel Jul 10 '14 at 11:32
  • I should add that just now we are found the reason why the project compiles in other's PC. The project itself is being compiled in the Ubuntu in virtual machine, but the directory where the source codes is , in one of the Windows directories that being mounted to the Ubuntu VM. – Hi-Angel Jul 11 '14 at 15:32
2

GCC doesn't care one bit what's between < and > in your #include directives. It just passes it all down to the OS. If your OS finds it, then GCC processes it. If it doesn't, it doesn't. If you create a file named foo\bar.h in your Linux directory (you can), and #include "foo\bar.h" in your source, it will be found.

You can tell your colleagues to shove their arrogance and fix their broken code.

n. m. could be an AI
  • 112,515
  • 14
  • 128
  • 243
2

Nothing a little sed can't fix :)

sed -i '/#include/s/\\/\//g' *.c *.h
pdw
  • 8,359
  • 2
  • 29
  • 41
  • I am accept this answer, as this is the solution, but I must tell that another replies is very much useful, and had big influence to the end decision. I am just learned a few the *regexps*, and the *sed* syntax, but still can't do anything helpful by myself. I.e. I dunno how to replace `UnkWrd1 foo UnkWrd1` with `UnkWrd1 bar UnkWrd2`, where *UnkWrd*s is unknown -- most needed thing I think. – Hi-Angel Jul 10 '14 at 19:02