TRUE&FALSE conflicts on alpha*-dec-osf4.0d

Tom Tromey tromey@cygnus.com
Mon Jul 19 23:13:00 GMT 1999


>>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:

Alexandre> This patch assumes that header files are well-behaved, in
Alexandre> the sense that they won't redefine TRUE and FALSE if
Alexandre> they're already defined, if they define them at all, or
Alexandre> that they'll be included before javaprims.h.  The first
Alexandre> alternative is probably reasonable; I'm not sure about the
Alexandre> second, but I can't see any clean solution other than
Alexandre> special-casing java/lang/Boolean.h's TRUE and FALSE in
Alexandre> gcjh, #undefining them just before their declarations.
Alexandre> It's probably not worth the trouble.

If it works in the currrent instance, it's good enough for me.  I'm
not very picky about this particular problem, since the long-term
solution isn't implemented yet.

In the long term we're going to special-case all losing words in
gcjh, and change the C++ compiler so that it will still generate the
symbol that we need.

For instance, "delete" will appear as something like this in the
header:

	__delete __attribute__ ((symbol, "delete"))

(details will differ)

"TRUE" and "FALSE" will end up on this list by virtue of being a real
pain, as you've discovered.

Alexandre> The choice of javaprims.h was arbitrary, it just seemed reasonable.

For now it is ok, since we're going to do a big header rewrite
sometime.  The plan there is to clean up the headers, clarify their
puposes, and separate installable from implementation headers.  This
is a prerequisite to really "exporting" CNI.

Alexandre> Here's the patch.

I'll try to check it in tomorrow.  I'm a bit swamped.

Tom


More information about the Java-patches mailing list