tree_code and type safety

[Thomas Neumann <tneumann at users dot sourceforge dot net>]

Hi,

while waiting for my copyright assignment, I continued compiling gcc
with a C++ compiler. Most problems are minor, but now I encountered one
where I am unsure what to do:

The basic tree codes are defined by the enum tree_code, that basically
looks like this:

enum tree_code {
   <lot of codes>
   LAST_AND_UNUSED_TREE_CODE
}

The C front end apparently needs additional tree codes, and defines them
like this:

enum c_tree_code {
  C_DUMMY_TREE_CODE = LAST_AND_UNUSED_TREE_CODE,
  <currently one C code>
}

So far ok, but then C front end passes its private tree code to
functions expecting tree_code values. This is not accepted by the C++
compiler, as tree_code and c_tree_code are distinct types.
In fact I think the code is undefined even in C unless something like
MAXIMUM_TREE_CODE = 65535 is added to tree_code and MINIMUM_TREE_CODE=0
is added to c_tree_code. (At least if the C++ standard paragraph 7.2.6
is similar to its C counterpart)

Now I have multiple options to fix this issue:

1) I could just explicitly cast from c_tree_code to tree_code. Avoids
the error, and is only needed about two or three times in the whole code
as there is only one C tree_code currently. But more tree code might be
added in the future and other front end might use more tree codes.

2) I could use an integer data type instead of an enum to hold the tree
code values. This avoids all problems, but is massively invasive: grep
"enum tree_code" returns 530 hits, changing all of these into tree_code
(as an integer typedef would not be in the enum namespace) would touch
many files. Probably not a good idea.

3) use preprocessor magic to add the front end tree codes into the tree
code enum, somewhat like this (just a rough sketch):

enum tree_code {
   <lot of codes>
   LAST_AND_UNUSED_TREE_CODE,
   FIRST_C_CODE = LAST_AND_UNUSED_TREE_CODE,
#include "c-common.def"
   FIRST_FOOLANG_CODE = LAST_AND_UNUSED_TREE_CODE,
#include "foolang-common.def"
}

This gets the enum reasonable, but has to know the front ends somehow.
Or perhaps it is enough to include the tree codes of the _current_ front
end, whatever it is. The preprocessor magic is probably not trivial, but
otherwise the rest of the code should not be affected.


I tend to just go for 1) and add the casts, but this is not very future
proof. Any suggestions?

Thomas