Re: Generating Java Bytecode

Russell Bornsch++ <kaleja@rahul.net>
3 Dec 1996 20:55:50 -0500

          From comp.compilers

Related articles
[20 earlier articles]
Re: Generating Java Bytecode gvreugde@uwaterloo.ca (1996-11-26)
Re: Generating Java Bytecode jaidi@ubd.edu.bn (Nor Jaidi) (1996-11-26)
Re: Generating Java Bytecode Freek.Wiedijk@phil.ruu.nl (1996-12-01)
Re: Generating Java Bytecode jsa@alexandria.organon.com (1996-12-01)
Re: Generating Java Bytecode jgreene@inmet.com (Jeremy Greene) (1996-12-01)
Re: Generating Java Bytecode Antoine.Leca@renault.fr (Antoine Leca) (1996-12-01)
Re: Generating Java Bytecode kaleja@rahul.net (Russell Bornsch++) (1996-12-03)
Re: Generating Java Bytecode derek@knosof.co.uk (1996-12-07)
| List of all articles for this month |

From: Russell Bornsch++ <kaleja@rahul.net>
Newsgroups: comp.compilers
Date: 3 Dec 1996 20:55:50 -0500
Organization: Compilers Central
References: 96-11-108 96-11-125 96-11-132 96-12-023
Keywords: Java, C

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.
--


Post a followup to this message

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