Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!eagle!icdoc!cam-cl!am
From: am@cl.cam.ac.uk (Alan Mycroft)
Newsgroups: comp.lang.c
Subject: Re: Types
Message-ID: <727@jenny.cl.cam.ac.uk>
Date: Wed, 17-Jun-87 11:47:45 EDT
Article-I.D.: jenny.727
Posted: Wed Jun 17 11:47:45 1987
Date-Received: Sat, 4-Jul-87 17:31:56 EDT
References: <7264@brl-adm.ARPA> <734@sdchema.sdchem.UUCP>
Reply-To: am@cl.cam.ac.uk (Alan Mycroft)
Organization: U of Cambridge Comp Lab, UK
Lines: 17

In article <546@haddock.UUCP> karl@haddock.ISC.COM.UUCP (Karl Heuer) writes:
>ANY use of asm() is both machine- and compiler-dependent.  X3J11 does not
>require that an implementation support asm() (it's a "Common Extension") or
>even that it have an assembly pass.
>
My understanding of the X3J11 OCtober 86 public review draft is
that a C compiler which treats
   f() { asm("ret"); }
as anything other than a call to the C function asm() with a pointer
to 4 bytes of initialised storage is broken.
(Of course, if you include a non-ansi header, or use a #pragma then
all bets are off as the program behaviour is unspecified.  However
the above use IS deprecated in asm() has not been declared previously).

I believe that the appendix listing of 'asm' is intended as a warning
to users who wish to write code which also works on older 'C's and
who might otherwise get burnt.