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

open
nobody
None
5
2012-10-02
2008-03-04
Howard Jeng
No

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++.

Discussion

  • Howard Jeng
    Howard Jeng
    2008-03-04

    0.23.4 modification for Borland C++

     
    Attachments
  • 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
    Howard Jeng
    2008-03-05

    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:

    include <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>.

    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.

     
  • 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.

     
  • Logged In: YES
    user_id=278191
    Originator: NO

    Tried to be implemented in 0.23.6.

     
  • Howard Jeng
    Howard Jeng
    2008-03-05

    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).

     
  • Logged In: YES
    user_id=278191
    Originator: NO

    Solved in 0.23.8

     
  • Howard Jeng
    Howard Jeng
    2008-03-07

    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 IndigoLexerU2_STRING_on_exit, IndigoLexerMODULE_on_exit, IndigoLexerU1_STRING_on_entry and IndigoLexerU1_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.

     
  • 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

    'IndigoLexerU2_STRING_on_exitSomething' 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
      Eugene
      2013-03-23

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

       

      • Anonymous
        2013-03-25

        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
    Howard Jeng
    2008-03-07

    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.

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

     
  • Howard Jeng
    Howard Jeng
    2008-10-07

    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

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

     
  • Howard Jeng
    Howard Jeng
    2008-11-14

    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.

     


Anonymous


Cancel   Add attachments