Re: Generating Java Bytecode

Joe Hummel wrote:
: ...
: But we have to be careful when we say "pointer". Ada has pointers,
: and working Ada-->bytecode compilers seem to exist. But I think the
: problem is in supporting general pointers, i.e. pointer arithmetic and
: pointers to any old location in RAM:
:
: void *p;
:
: p = (void *) 0x0080001F; /* some memory location */
: *((int *) p) = 10; /* let's store 10 there */
: p++;


Antoine Leca wrote:
> Stop.
> I'm no C legalist, but from what I understand about C "undefined
> behavior", there is a perfect example of it (BTW, this concept
> is very near to the concept of erroneous in Ada83).
>
> And a given C compiler is able to do whatever it want with undefined
> behavior, including rejecting the program at compile-time.


Please forgive the topic drift and C-legalese rant here...


I'm not a C legalist in the sense of knowing the standards document
chapter-and-verse, but this code is "legal C" in the sense that it
should compile to code that does *something* - that something happens
to be dependent on the execution environment, therefore, it has
undefined behavior. (I'm ignoring for the moment that last pointer
increment (p++), which - again, I *think* - the compiler will warn or
refuse (void has no size), unless it's GNU, in which case who cares
about standards anyway... :)


Casting is part of C. Casting an integer constant to a pointer
_creates a valid pointer_. The pointer may or may not be useful. Any
compiler that refuses to compile that chunk of code should be taken
out and shot.


Consider that the C standard library is traditionally implemented
in C. If the compiler can reject that code, malloc() gets very
challenging.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.