0

I'm trying to compile 3 cpp files, for only one of them, the g++ compiler on linux is reading spaces between every character on the making it impossible to compile. I get hundreds, if not thousands, of x.cpp:n:n: warning: null character(s) ignored (where x is a name and n is a number). I wrote the program in Visual studio and I copied them to linux. The other 2 files compile fine, I've done this for dozens of projects. How does this happen?

I managed to fix this issue by creating a new file and copying the text from the original cpp instead of copying the file.

Now I get an error from the terminal saying Permission Denied when I try launch the .o file

griffin175
  • 131
  • 6
  • I'm fairly certain that newlines via linux / windows can be different. Not always a simple thing to copy one file over from one OS and read it in another without compatibility issues. Probably during the copy / paste operation it automatically fixed the newline characters to be more friendly to the linux compiler – Ilan Keshet Jun 16 '18 at 04:13
  • The Permission Denied, is probably something else entirely – Ilan Keshet Jun 16 '18 at 04:14
  • 1
    Look up dos2unix (if taking a file from a windows machine to unix) and unix2dos (if going the other way). Handling of newlines (in particular) and other characters is different, and those programs filter files accordingly. The cause will be related to how you transfer the files (e.g. in binary versus text mode). – Peter Jun 16 '18 at 04:15
  • The .o file is object file, it is not executable. Thus you get "Permission Denied", the system are not permitted ti run object files. – 273K Jun 16 '18 at 04:22
  • @Ken White I don't normally copy/paste the code in, but that's how I had to do it to solve this issue. The line endings aren't even the issue here. The issue is that spaces are being added between characters where there was never a space before. What I've always done is write the code in visual studio and copied the cpp files. This has never been an issue until now and it's only happening to one of the 4 files copied – griffin175 Jun 16 '18 at 04:40
  • The spaces are caused by saving the file as Unicode rather than ASCII. The line endings are also an issue. In the VS code editor, right-click and choose to save the file in a format other than Unicode. – Ken White Jun 16 '18 at 04:42
  • @KenWhite I _think_ that gcc will accept CRLF these days. I do this routinely on the Mac at any rate and it always seems fine. – Paul Sanders Jun 16 '18 at 05:47

2 Answers2

3

Your compiler problem is nothing to do with linebreaks.

You're trying to compile a file saved as UTF-16 (Unicode). Visual Studio will do this behind your back if the file contains any non-ASCII characters.

Solution 1 (recommended): stick to ASCII. Then the problem simply won't arise in the first place.

Solution 2: save the file in Visual Studio as UTF-8, as described here. You might need to save the file without a BOM (byte-order mark) as described here.

WRT your other problem, look for a file called a.out (yes, really) and try running that. And don't specify -c on the g++ command line.

Paul Sanders
  • 24,133
  • 4
  • 26
  • 48
  • Your version if Visual Studio might be outdated. In VS 2015.3, when I added "Hello, " to my cpp file in a fresh project, I was asked if I wanted to convert it to "Unicode". "Yes" resulted in UTF-8 with a BOM. (BTW—a Unicode text reader that doesn't read, use and discard the BOM is non-compliant, regardless if it is remcommended for UTF-8.) – Tom Blodget Jun 17 '18 at 16:47
  • @TomB Interesting. I just ran a few quick tests and my version (which is VS 2017) saves such a file (I used that very character) as UTF-8 _without_ a BOM, and it did this without prompting me. I'm sure this behaviour has changed at some point in the relatively recent past because VS once saved one of my .rc files as UTF-16 without telling me and it played merry hell with my source code control system. I also checked that MSVC would compile that file, both with and without a BOM and it did so just fine. Whether the g++ will understand the BOM I don't know, but one would hope so. – Paul Sanders Jun 17 '18 at 17:09
  • 1
    @TomB Anyway, this is all excellent news. I don't know what version of VS the OP is using or exactly how his file got converted to UTF-16, I only know that's what he ended up with. But hopefully, Visual Studio won't be inflicting that particular form of misery on us any longer, hallelujah. Well done M$, you're geting there. OP **please make note of this conversation**, it might be important to you to know what we have discovered here. – Paul Sanders Jun 17 '18 at 17:11
0

There is no text but encoded text.

Dogmatic corollaries:

Authors choose a character encoding for a text file.

Readers must know what it is.

Any kind of shared understanding will do: specification, convention, internal tagging, metadata upon transfer, …. (Even last century's way of converting upon transfer would do in some cases.)

It seems you 1) didn't know what you chose. 2) didn't bring that knowledge with you when you copied the file between systems, and 3) didn't tell GCC.

Unfortunately, there has been a culture of hiding these basic communication needs, instead of doing it mindfully; so, your experience too much too common.

To tell GCC,

g++ -finput-charset=utf-16

Obviously, if you are using some sort of project system that supports keeping track of the required metadata of the relevant text files and passing it tools, that would be preferred.

You could try adopting UTF-8 Everywhere. That won't eliminate the need for communication (until maybe the middle of this century) but it could make it more agreeable.

Tom Blodget
  • 20,260
  • 3
  • 39
  • 72
  • _It seems you ... didn't know what you chose_ Well, to be fair to the OP, he didn't make a conscious choice at all, that's why he came looking for help. And he got it, that's why this site exists. – Paul Sanders Jun 17 '18 at 17:14
  • @PaulSanders Yes, not making a conscious choice is a problem that people have to been led into. It was meant in the spirit of helpfulness. – Tom Blodget Jun 18 '18 at 16:52
  • Yes, understood. – Paul Sanders Jun 19 '18 at 07:15