From owner-cvs-all  Mon Dec 11  3:51:29 2000
From owner-cvs-all@FreeBSD.ORG  Mon Dec 11 03:51:25 2000
Return-Path: <owner-cvs-all@FreeBSD.ORG>
Delivered-To: cvs-all@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id 27BB837B404; Mon, 11 Dec 2000 03:51:22 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id WAA19347;
	Mon, 11 Dec 2000 22:50:06 +1100
Date: Mon, 11 Dec 2000 22:51:31 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
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 
In-Reply-To: <200012101702.eBAH22I29827@gratis.grondar.za>
Message-ID: <Pine.BSF.4.21.0012112240150.4160-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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