Date: Mon, 11 Dec 2000 22:51:31 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Mark Murray <mark@grondar.za> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Jeroen Ruigrok van der Werven <asmodai@FreeBSD.org>, John Baldwin <jhb@FreeBSD.org>, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/tail forward.c read.c reverse.c tail Message-ID: <Pine.BSF.4.21.0012112240150.4160-100000@besplex.bde.org> In-Reply-To: <200012101702.eBAH22I29827@gratis.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 10 Dec 2000, Mark Murray wrote:
[Garret Wollman wrote]
> > Actually, the `register' keyword is *not* ignored by compilers, and
> > *does* serve a purpose (which may or may not turn out to be useful).
> > Variables with the `register' storage class may not have their
> > addresses taken, and the compiler is required to emit a diagnostic if
> > you try. The C compiler can not store a variable in a register across
> > a function call if its address is ever taken. (This is important for
> > SPARC processors, but less so on ia32 since there are only two
> > call-preserved registers.)
>
> Wrong. As of ANSI, "register" variables _may_ have their addresses
> taken, and the "register" keyword is officially a *hint*, not an
> instruction.
From the C99 draft (n869.txt):
6.5.3.2 Address and indirection operators
Constraints
[#1] The operand of the unary & operator shall be either a
^^^^^
function designator, the result of a [] or unary * operator,
or an lvalue that designates an object that is not a bit-
field and is not declared with the register storage-class
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
specifier.
^^^^^^^^^
This hasn't changed significantly since K&R1.
You should know better than to meddle in the affairs of language lawyers :-).
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0012112240150.4160-100000>