This illustrates the difference between a language with no dangerous constructs, and one where you must trust the implementation.
From some internal OSF email: ---------- Begin Forwarded Message ----------
class Data { // an object storing 16 bytes byte word[16]; }
class Trick { Data data; long tricky_pointer; }
Now suppose, I fake a compiler (or I have a malicious compiler) and I generate by hand malicious byte code such that in the symbol tables, tricky_pointer and data have the same offset.
What offset do you mean? The offset in the struct as in C++? Java bytecode does not store such information. Fields are accessed using putfield/getfield, which use an index to a field reference in the constant pool. (pg. 66, lang spec) Field references contain a name index (pg. 19) which points to a name, i.e., a CONSTANT_Utf8 (pg. 18) field. To my knowledge, the Java, and Java bytecode does not imply any memory layout. I doubt it makes sense to demand to check that 'offset do not overlap in memory'. Could you describe in more detail the manipulation you are proposing? - Godmar