Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior

pardo@june.cs.washington.edu (David Keppel)
Fri, 12 Apr 91 20:57:21 GMT

          From comp.compilers
Related articles
Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior carter@cs.wisc.edu (1991-04-06)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior ckp@grebyn.com (1991-04-08)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior albaugh@dms.UUCP (1991-04-09)
Re: Borland Turbo C 2.0 for Atari 68000 machines: ODD behavior pardo@june.cs.washington.edu (1991-04-12)
| List of all articles for this month |
Newsgroups: comp.compilers,comp.lang.c
From: pardo@june.cs.washington.edu (David Keppel)
Followup-To: comp.lang.c,comp.sys.m68k
Keywords: C, code, question
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <1991Apr6.091013.26131@daffy.cs.wisc.edu>
Date: Fri, 12 Apr 91 20:57:21 GMT

carter@cs.wisc.edu (Gregory Carter) writes:
> (unsigned int)(*((unsigned int *)0xffff8e20L)) = 0x03;
>translates to:
> MOVE.W #$0003, $8e20
>This is obviously not correct.


I'll agree that it isn't what I *expected* but it is *correct*.
Here are some other correct implementations:


  * Compiler refuses to compile the program
  * Program aborts when executed
  * Program runs `rogue'
  * Program assigs 3 to memory location 0xffff8e20


Remember, dereferencing a hard-coded address (in C) has
implementation-defined effect.


In the meanwhile, I agree that the one it chose is non-intuitive.


Followups to `comp.lang.c' and `comp.sys.m68k'.


;-D on ( Paid-up in tuition ) Pardo
--

Post a followup to this message

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