From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9043 invoked from network); 19 Feb 2004 10:50:23 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 19 Feb 2004 10:50:23 -0000 Received: (qmail 9409 invoked by alias); 19 Feb 2004 10:50:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19449 Received: (qmail 9370 invoked from network); 19 Feb 2004 10:50:15 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 19 Feb 2004 10:50:15 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [63.249.88.2] by sunsite.dk (MessageWall 1.0.8) with SMTP; 19 Feb 2004 10:50:14 -0000 Received: by binome.blorf.net (Postfix, from userid 1000) id C48CDC8D2; Thu, 19 Feb 2004 02:50:13 -0800 (PST) Date: Thu, 19 Feb 2004 02:50:13 -0800 From: Wayne Davison To: Peter Stephenson Cc: Zsh hackers list Subject: Re: Strict-aliasing warnings Message-ID: <20040219105013.GD26450@blorf.net> References: <20040219102029.GB26450@blorf.net> <1728.1077186812@csr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1728.1077186812@csr.com> User-Agent: Mutt/1.5.5.1+cvs20040105i On Thu, Feb 19, 2004 at 10:33:32AM +0000, Peter Stephenson wrote: > The warning is highly obscure but my guess is it's worried because it > doesn't know that the type we're looking at really does look like a > HashNode. Kind of, but only in the context of modern aliasing restrictions. If two aliases for a single memory location differ in type in a radical enough manner, the compiler does not have to consider that the two different references might affect one another. E.g. you could change a variable from one pointer and not have that change get reflected in the reading from another pointer (or the original variable) because the compiler might have optimized away the memory-fetch. However, certain casts force the compiler to be less aggressive in its optimizations (such as (char *) and (void *)). That is the intent of using the (void *) cast -- it _should_ let the optimizer know that that variable needs to be refetched. However, I'm not 100% sure that this is enough to make sure that the optimizations are valid or if it's only enough to just silence the warnings. ..wayne..