Re: Generating Java Bytecode

derek@knosof.co.uk (Derek M Jones)
7 Dec 1996 23:06:31 -0500

          From comp.compilers

Related articles
[21 earlier articles]
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: derek@knosof.co.uk (Derek M Jones)
Newsgroups: comp.compilers
Date: 7 Dec 1996 23:06:31 -0500
Organization: Knowledge Software Ltd
References: 96-11-108 96-11-125 96-11-132 96-12-023 96-12-043
Keywords: Java, C

All,




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


kaleja@rahul.net "Russell Bornsch++" writes:
> 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


The C standard does not define the concept of "legal C". A program may
either be non-conforming, conforming or strictly conforming.


> should compile to code that does *something* - that something happens


Not necessarily.


To be conforming a translation unit has to be acceptable to a
conforming implementation. I know of a number of conforming
implementations that will accept the above. So the code is
conforming.


To be strictly conforming a translation unit must not contain any
violations of syntax, constaints, undefined, implementation defined or
unspecified behaviours and it should not exceed any limits
(essentially it must be acceptable to all conforming implementations).


Casting an integer to a pointer is implementation defined behaviour
(ISO C 9899:1990 Clause 6.3.4, semantics). So the code is not
strictly conforming.


The requirements for implementation defined behaviour is that an
implementation must document it. The documentation might say "it
works exactly the way you want it", or it might say "when this
construct is detected the compiler formats your hard disc". The
requirement is on the existence of documentation, not behaviour.


> 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


No, it need not. See above.


derek


--
Derek M Jones tel: +44 (0) 1252 520 667
Knowledge Software Ltd email: derek@knosof.co.uk
Applications Standards Conformance Testing http://www.knosof.co.uk
--


Post a followup to this message

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