#3 Modification to 0.23.4 to compile with Borland C++

[Howard Jeng]

File modifications for 0.23.4 to allow quex generated code to compile with Borland's 2006 C++ compiler.

This required the creation of a new header for integer types (/code_base/compatibility/win/borland_int.h) and modifications so that the header would be included if being compiled with Borland's C++ compiler.

Also in a few places, quex relied on non-standard behavior in standard headers. Include files like cstdio and cstdlib are only guaranteed by the C++ standard to place the definitions in the std namespace, though many compilers, like gcc and MSVC, also place the definitions in the root namespace. However, Borland does not do this. Quex was including the cstdio and using definitions from the root namespace rather than the std namespace, so would fail to compile under Borland C++.

[Howard Jeng]

0.23.4 modification for Borland C++

[Frank-Rene Schäfer]

Logged In: YES
user_id=278191
Originator: NO

Thanks for the Borland adaptions.

However, I am not aware, that g++ does place definitions
in the root namespace. It has been probably 10 years
that this is not longer the case (ca. gcc 2.9.5 or so).

In any case, it is better to refer to definitions explicitly
either by "using namespace X" or "X::" prefixes. Would you
mind pointing the places where the quex produced code relies
on placement of "std::" and others in the root namespace?

Thanks.

[Howard Jeng]

Logged In: YES
user_id=1998775
Originator: YES

I know what you're thinking about. The gcc compiler used to use namespace std as an alias for the root namespace, but that's not what I'm referring to here. If you look at the source for the <cstdio> header in gcc (well 3.4.2 and 3.4.4 anyways), you'll see it does something like:</cstdio>

include <stdio.h></stdio.h>

namespace std {
using ::FILE;
using ::fpos_t;
//...
}

This puts the declarations in the root namespace first and then imports them into the std namespace, which means that when you #include <cstdio>, you have the declarations in both namespaces. However, the C++ standard only guarantees that when you #include <cstdio> the declarations are available in the std namespace. In order for the definitions to be guaranteed to be in the root namespace you need to #include <stdio.h>.</stdio.h></cstdio></cstdio>

In any case, here is a list of places that rely on symbols being in the root namespace:
input_strategy:42 FILE
input_strategy:45 FILE
input_strategy:53 FILE

buffer_core.i:276 abort
buffer_core.i:279 abort

circular_queue:94-99 abort

generated Lexer-token_ids file:map_id_to_name() sprintf
generated Lexer. file:Lexer constructor declaration FILE
generated Lexer. file:Lexer(const std::string &, const char ) definition FILE, fopen
generated Lexer. file:Lexer(FILE , const char *) definition FILE

This list may not be complete.

[Frank-Rene Schäfer]

Logged In: YES
user_id=278191
Originator: NO

I'd vote for a little ping pong game. Let me do the changes
and you're gonna tell me if everything works out propperly.
I'll try to find a way to detect the places on my own, so
it's hoperfully not going to take too many iterations.

[Frank-Rene Schäfer]

Logged In: YES
user_id=278191
Originator: NO

Tried to be implemented in 0.23.6.

[Howard Jeng]

Logged In: YES
user_id=1998775
Originator: YES

The generated source file Lexer. contains a call to fopen() in the Lexer(const std::string &, const char *) constructor and the generated source file Lexer-token_ids contains a call to sprintf() in token::map_id_to_name(const token::id_type).

[Frank-Rene Schäfer]

Logged In: YES
user_id=278191
Originator: NO

Solved in 0.23.8

[Howard Jeng]

Logged In: YES
user_id=1998775
Originator: YES

No longer getting standard library errors. However, it's generating E2178 errors with some functions. The help document entry for E2178 is:

"""
VIRDEF name conflict for 'function' (E2178)

The compiler must truncate mangled names to a certain length because of a name length limit that is imposed by the linker. This truncation may (in very rare cases) cause two names to mangle to the same linker name. If these names happen to both be VIRDEF names, the compiler issues this error message. The simplest workaround for this problem is to change the name of 'function' so that the conflict is avoided.
"""

This happens with the indigo lexer file with the functions IndigoLexer__U2_STRING_on_exit, IndigoLexer__MODULE_on_exit, IndigoLexer__U1_STRING_on_entry and IndigoLexer__U1_STRING_on_exit. Renaming the output engine from IndigoLexer to Indigo or Test doesn't seem to fix things either. Quite frankly I have no idea what the problem is, since renaming doesn't seem to help things.

[Frank-Rene Schäfer]

Logged In: YES
user_id=278191
Originator: NO

Well, to me also this seems medieval. I do not remember having
come across a C/C++ compiler that puts serious constraints on name
length. What I could possibly imagine is that Borlands linker
convention codes the types of the arguments in the function name
and that IndigoLexer__U2_STRING_on_exit produces a linker name
that is ambigous, e.g. perhaps

'IndigoLexer__U2_STRING_on_exit(Something)' becomes

'IndigoLexer__U2_STRING_on_exit__Something' in the object file
which could stand also for a function receiving
"U2_STRING_on_exit" and "Something" as an argument.
Maybe, ...

Are interested in solving this problem? Is the Borland compiler
actually still supported?

[Eugene]

It looks like Borland is complaining about identifiers using double underscore, which the C++ standard explicitly prohibits, though most compilers don't care.

[Anonymous]

Thanks, I must admit that I was not aware of this
prohibition. This will result in a major modification
in the code base. Once this is done, would you be willing
to double check with the Borland Compiler?

Thanks

[Howard Jeng]

Logged In: YES
user_id=1998775
Originator: YES

Borland comes out with pretty close to yearly updates for their compiler. I'll see if I can find someone with the 2007 edition and see if it compiles, then we can write this off as a compiler bug.

[Frank-Rene Schäfer]

Does this issue still occur with Borland in 0.31.x?

[Howard Jeng]

It's still not compiling, but for a different reason this time. Right now it gives the error

[C++ Error] Buffer_debug.i(64): E2108 Improper use of typedef 'uint8_t'

referring to the line

if QUEX_CHARACTER_TYPE == uint8_t

[Frank-Rene Schäfer]

Does the issue with Borland C still occur with the new buffer design?

[Howard Jeng]

In 0.33.4, it's still generating the improper use of typedef on line 64 of Buffer_debug.i.

Also, there's a new error: in the generated lexer file, in class CLASS, there's a FILE * declaration that's missing a std:: prefix.