1

I'm working on a C++ project that is compiled on a few platforms, including Windows, Linux, and Solaris.

The Solaris version of the code is quite old. I'm updating it with changes made over several years, and getting weird compiler errors with code that compiles fine on Windows and Linux.

GCC is version 2.95.3, on Solaris 9 (SunOS 5.9). I'm aware that these are very old versions.
The weird errors are "parse error before", followed by a hexadecimal number that doesn't appear in the source files.

Here's a small sample of the errors (not all of them) for one source file:

./InDB/InDB/Column.cpp: In method `bool InDB::IndexSorter::operator ()(unsigned int, unsigned int)':
./InDB/InDB/Column.cpp:27: parse error before `0x00000002'
./InDB/InDB/Column.cpp: In method `int InDB::Column::load()':
./InDB/InDB/Column.cpp:110: parse error before `0x00000020'
./InDB/InDB/Column.cpp:111: initialization of non-const reference type `int &'
./InDB/InDB/Column.cpp:111: from rvalue of type `int'

Here's the function in Column.cpp that contains line 27:

bool IndexSorter::operator()(unsigned int _Lhs, unsigned int _Rhs) {
//  Get the two records
    unsigned int _L = Cp->getLookupIndexAt(_Lhs);  // Line 27
    unsigned int _R = Cp->getLookupIndexAt(_Rhs);

//  Now do the comparison
    return (_L < _R);
}

This function hasn't changed at all between the old, working version of the Solaris code, and the current version, but there are several other changes in the same source file.

What do the hexadecimal numbers mean in the error messages?
How can I fix this?

Scott Leis
  • 2,810
  • 6
  • 28
  • 42
  • 4
    Then names starting with `_` followed by an upper-case character are reserved for the implementation. I would start by fixing that. – juanchopanza Jun 21 '15 at 06:36
  • 1
    See related post: http://stackoverflow.com/questions/228783/what-are-the-rules-about-using-an-underscore-in-a-c-identifier – juanchopanza Jun 21 '15 at 07:49

1 Answers1

4

usr/include/iso/ctype_iso.h from Solaris 8 defines _L:

#define _U  0x00000001  /* Upper case */
#define _L  0x00000002  /* Lower case */
#define _N  0x00000004  /* Numeral (digit) */
#define _S  0x00000008  /* Spacing character */
#define _P  0x00000010  /* Punctuation */
#define _C  0x00000020  /* Control character */
#define _B  0x00000040  /* Blank */
#define _X  0x00000080  /* heXadecimal digit */

This is breaking your code. These defines are specific to Solaris, though you should not be using these kinds of identifiers in the first place as @juanchopanza points out.

Your best bet is to simply rename those identifiers to something more legal (simply Lhs, Rhs and L, R should work since these are local variables).

nneonneo
  • 171,345
  • 36
  • 312
  • 383
  • It makes no sense that these identifiers are only causing problems now, since the exact same function compiles fine in an earlier version of the code on the same machine. I'll try changing them anyway, but I may find many similar problems elsewhere in the code. Previous developers of the project made extensive use of short variable names beginning with underscores. – Scott Leis Jun 21 '15 at 07:13
  • 1
    @ScottLeis: The simplest cause I can think of is that you started including `` somewhere, which includes the offending header. – nneonneo Jun 21 '15 at 07:16
  • A search of the whole project code doesn't show up `` anywhere. Perhaps some other file outside the project includes that one? There certainly have been some includes added to the project. – Scott Leis Jun 21 '15 at 07:23
  • 1
    You can always do a `g++ -E` to try to tease out where a particular `#include` is coming from. It could definitely be an `#include` outside the project. – nneonneo Jun 21 '15 at 07:25
  • @ScottLeis Still, the code should not be using reserved names. Any code that uses them and uses the standard library exhibits undefined behaviour anyway. So, you (or the culprit) should fix that. – juanchopanza Jun 21 '15 at 07:46
  • @juanchopanza - Understood. It'll be me fixing it since the culprit left the company years ago. I had no idea these were reserved names, and the culprit probably didn't know that either. – Scott Leis Jun 21 '15 at 07:48
  • I do want to point out that this kind of failure can occur even if you don't use reserved names. See https://svn.boost.org/trac/boost/ticket/10467 for an example of a failure I uncovered on OS X - the symbol `B0` from `sys/termios.h` caused compilation failures in Boost.Geometry. – nneonneo Jun 21 '15 at 08:35
  • 2
    I've confirmed that my code is indirectly including `ctype_iso.h`, and the defines from that file cause the problem (and if I ever see the original developer of this project again, I'll let him know what a PITA it is to work with his code). – Scott Leis Jun 22 '15 at 04:03