From mboxrd@z Thu Jan 1 00:00:00 1970 From: Per Bothner To: law@cygnus.com Cc: Mark Klein , egcs@egcs.cygnus.com, java-discuss@sourceware.cygnus.com Subject: Re: assemble_external on .class files Date: Mon, 31 May 1999 21:36:00 -0000 Message-ID: References: <21069.927686125@upchuck.cygnus.com> X-SW-Source: 1999-05n/msg00709.html Message-ID: <19990531213600.rUFzkz3A-72NX1Cmsh3bp9pHYQloWfit986wYVcRZ4s@z> Jeffrey A Law writes: > Split up DECL_EXTERNAL and METHOD_NATIVE. It seems awful strange/wrong to > have them overloaded on the same bit. Can someone from the Java side > explain why they're using the same bit? Especially since DECL_EXTERNAL has > a well defined meaning already. It seems to me using a lang specific flag > would make a lot more sense for METHOD_NATIVE. Well, the logic was the assumption that they would always be the same. In a Java class, we have three kinds of methods: (1) Regular methods (static or instance), with method bodies in the class body. These methods are neither native, nor external, since they are declared in the current input (.java or .class) file. (2) Native methods, which do not have bodies. These must be bound to some methods defined in some extenal C++ file. Hence, they need to have DECL_EXTERNAL set - as well as METHOD_NATIVE. (3) Abstract methods - which have no bodies anywhere. If they are ever referenced, it would be a compiler bug. I skimmed the earlier messages in this thread, which may be why I still don't understand why there would be any reason to split up the flags. However, perhaps there should be a comment where METHOD_NATIVE is defined. Something like the following may suffice: /* Only native methods are external (and vice versa). */ or perhaps: /* A method is external if and only if it is native. */ -- --Per Bothner bothner@pacbell.net http://home.pacbell.net/bothner/