Geek Answers Handbook

Strange gcc bug: wandering '\ nNN' in program

The following problem appeared in my open source library, and I cannot figure out what is going on.

Two of my users have (gcc) compiler errors that look like this:

/home/someone/Source/src/._regex.cpp:1:1: warning: null character(s) ignored /home/someone/Source/src/._regex.cpp:1: error: stray '\5' in program /home/someone/Source/src/._regex.cpp:1: error: stray '\26' in program /home/someone/Source/src/._regex.cpp:1: error: stray '\7' in program /home/someone/Source/src/._regex.cpp:1:5: warning: null character(s) ignored /home/someone/Source/src/._regex.cpp:1: error: stray '\2' in program ...

I cannot reproduce these errors; The code compiles on all the machines I tested.

It seems like a googling search indicates that this often happens due to weird encoding or weird formatting, but I ran all the source code using a hex editor, and all characters are either ASCII printable (0x20 - 0x7E) or tabs. or a new line. What is it.

In addition, both users successfully compiled the previous version of the library; but the specific file ( regex.cpp ) and its header files have not been changed since that time!

See here for more details, including links to download the code if you want. But I would be pleased only with a pointer in a possible direction.

+6
c ++ gcc compiler-errors character-encoding
source share
5 answers

Baffe Boyois has the right general answer - your CMake rules should do too much.

On MacOS X 10.5.8 (Leopard) I get:

 Osiris JL: cmake .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Configuring done -- Generating done -- Build files have been written to: /Users/jleffler/tmp/yaml-cpp-0.2.3/build Osiris JL: make Scanning dependencies of target yaml-cpp [ 2%] Building CXX object CMakeFiles/yaml-cpp.dir/src/._conversion.cpp.o /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1:1: warning: null character(s) ignored /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1: error: stray '\5' in program /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1: error: stray '\22' in program /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1: error: stray '\7' in program /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1:5: warning: null character(s) ignored /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1: error: stray '\2' in program /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1:7: warning: null character(s) ignored /tmp/yaml-cpp-0.2.3/src/._conversion.cpp:1:17: warning: null character(s) ignored ...

You must specify the files you need to compile; you should not just compile everything and everything.

The problem seems to be in CMakeLists.txt:

 file(GLOB public_headers include/*.h) file(GLOB private_headers src/*.h) file(GLOB sources src/*.cpp)

Either CMake GLOB is a little enthusiastic (I use version 2.6-patch 4), or you cannot afford to use it while any of your clients use MacOS X.

What GLOB does the extension to include files starting with '.' anyone guesses; I would be inclined to regard this as a mistake in cmake.

However, as a workaround, I edited CMakeLists.txt and got this to work:

 file(GLOB public_headers include/[az]*.h) file(GLOB private_headers src/[az]*.h) file(GLOB sources src/[az]*.cpp)

This is not a complete solution: I encountered a continuation of the problem with the code in the yaml-reader directory. I changed the yaml-reader / CMakeLists.txt file in basically the same way.

FWIW:

 $ file ._* ._conversion.cpp: AppleDouble encoded Macintosh file ._exp.cpp: AppleDouble encoded Macintosh file ._map.cpp: AppleDouble encoded Macintosh file ._map.h: AppleDouble encoded Macintosh file ._node.cpp: AppleDouble encoded Macintosh file ._null.cpp: AppleDouble encoded Macintosh file ._ostream.cpp: AppleDouble encoded Macintosh file ._parser.cpp: AppleDouble encoded Macintosh file ._regex.cpp: AppleDouble encoded Macintosh file ._regeximpl.h: AppleDouble encoded Macintosh file ._scanner.cpp: AppleDouble encoded Macintosh file ._scanner.h: AppleDouble encoded Macintosh file ._scanscalar.cpp: AppleDouble encoded Macintosh file ._scanscalar.h: AppleDouble encoded Macintosh file ._sequence.cpp: AppleDouble encoded Macintosh file ._simplekey.cpp: AppleDouble encoded Macintosh file ._stream.cpp: AppleDouble encoded Macintosh file ._token.h: AppleDouble encoded Macintosh file $ odx ._con*.cpp 0x0000: 00 05 16 07 00 02 00 00 4D 61 63 20 4F 53 20 58 ........Mac OS X 0x0010: 20 20 20 20 20 20 20 20 00 02 00 00 00 09 00 00 ........ 0x0020: 00 32 00 00 00 79 00 00 00 02 00 00 00 AB 00 00 .2...y.......... 0x0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ * 0x0050: 00 00 00 00 41 54 54 52 00 3C E0 2B 00 00 00 AB ....ATTR.<.+.... 0x0060: 00 00 00 9C 00 00 00 0F 00 00 00 00 00 00 00 00 ................ 0x0070: 00 00 00 00 00 00 00 01 00 00 00 9C 00 00 00 0F ................ 0x0080: 00 00 17 63 6F 6D 2E 61 70 70 6C 65 2E 54 65 78 ...com.apple.Tex 0x0090: 74 45 6E 63 6F 64 69 6E 67 00 00 00 55 54 46 2D tEncoding...UTF- 0x00A0: 38 3B 31 33 34 32 31 37 39 38 34 8;134217984 0x00AB: $

One odd detail - some of the files in the 'src' directory do not have shadow files. When I do "tar -tvf yaml-cpp-0.2.3.tar.gz", I see that the files are being sent along with the source:

 Osiris JL: tar -tvf yaml-cpp-0.2.3.tar.gz drwxr-xr-x beder/staff 0 2009-10-22 15:13:52 ./ -rw-r--r-- beder/staff 1750 2009-10-22 15:09:05 ./CMakeLists.txt drwxr-xr-x beder/staff 0 2009-10-19 16:40:15 ./include/ -rw-r--r-- beder/staff 171 2009-09-06 13:41:54 ./include/._conversion.h -rw-r--r-- beder/staff 1118 2009-09-06 13:41:54 ./include/conversion.h -rw-r--r-- beder/staff 302 2009-07-29 15:25:23 ./include/crt.h -rw-r--r-- beder/staff 2254 2009-10-19 16:40:14 ./include/emitter.h -rw-r--r-- beder/staff 1660 2009-10-19 16:40:14 ./include/emittermanip.h -rw-r--r-- beder/staff 171 2009-08-18 22:07:22 ./include/._exceptions.h -rw-r--r-- beder/staff 5638 2009-08-18 22:07:22 ./include/exceptions.h -rw-r--r-- beder/staff 765 2009-07-29 15:25:23 ./include/iterator.h -rw-r--r-- beder/staff 444 2009-07-29 15:25:23 ./include/mark.h -rw-r--r-- beder/staff 171 2009-09-06 12:25:12 ./include/._node.h -rw-r--r-- beder/staff 3467 2009-09-06 12:25:12 ./include/node.h -rw-r--r-- beder/staff 171 2009-09-15 20:54:20 ./include/._nodeimpl.h ... -rw-r--r-- beder/staff 171 2009-07-29 21:28:26 ./include/._yaml.h -rw-r--r-- beder/staff 321 2009-07-29 21:28:26 ./include/yaml.h -rw-r--r-- beder/staff 167 2009-09-05 16:01:06 ./._install.txt -rw-r--r-- beder/staff 652 2009-09-05 16:01:06 ./install.txt -rw-r--r-- beder/staff 1073 2009-05-29 19:31:21 ./license.txt drwxr-xr-x beder/staff 0 2009-10-22 14:49:11 ./src/ -rw-r--r-- beder/staff 1697 2009-08-24 16:28:46 ./src/aliascontent.cpp -rw-r--r-- beder/staff 1171 2009-08-24 16:28:46 ./src/aliascontent.h -rw-r--r-- beder/staff 112 2009-05-29 19:31:21 ./src/content.cpp -rw-r--r-- beder/staff 1557 2009-08-24 16:28:46 ./src/content.h -rw-r--r-- beder/staff 171 2009-09-06 13:31:56 ./src/._conversion.cpp -rw-r--r-- beder/staff 2027 2009-09-06 13:31:56 ./src/conversion.cpp ...

Thus, miscreant files are sent along with the tar file. You got infected somewhere - you don’t know how to do it.

+7
source share

Errors are in ._regex.cpp , not regex.cpp . Files watching with ._ are automatically generated by MacOS. It seems your build system is trying to compile all files ending in .cpp. He probably shouldn't compile anything starting from the point.

+13
source share

There may be a damaged file on their part.

What's in line 1 _regex.cpp on their system.

If you have a problem with downloading / encoding, you will have to see what is in the files on their system, and not in your code repository.

0
source share

Make sure that you have only .o files in the assembly directory. I had this problem and the cause was an error in my Makefile (actually it was a scons file) which built one source file in a .c file instead of a .o file. The resulting file was binary, but I assume gcc tried to interpret it as a .c file.

0
source share

I just happened to my C ++ program that I was doing. This happened when I copied the double hash formula from the pdf file, which was

 return (randomNumber % (tableSize - 2)) + 1;

I was the modulo operator through this, but it turned out to be an encoding or something, but I solved this by deleting it and manually typing it.

0
source share

More articles:


All Articles