From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4884 invoked from network); 2 Mar 2004 02:45:02 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 2 Mar 2004 02:45:02 -0000 Received: (qmail 27779 invoked by alias); 2 Mar 2004 02:44:56 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19517 Received: (qmail 27730 invoked from network); 2 Mar 2004 02:44:56 -0000 Received: from localhost (HELO sunsite.dk) (127.0.0.1) by localhost with SMTP; 2 Mar 2004 02:44:56 -0000 X-MessageWall-Score: 0 (sunsite.dk) Received: from [170.148.93.20] by sunsite.dk (MessageWall 1.0.8) with SMTP; 2 Mar 2004 2:44:56 -0000 Received: from emanpe08.ny.jpmorgan.com (emanpe08.jpmorgan.com [10.21.212.208]) by emanpe02.jpmorgan.com (J.P. Morgan Chase & Co.) with ESMTP id i222ipQx012655; Mon, 1 Mar 2004 21:44:51 -0500 (EST) Received: from mrszip.ny.jpmorgan.com (mrszip.ny.jpmorgan.com [10.21.11.18]) by emanpe08.ny.jpmorgan.com (8.12.9/8.12.9) with ESMTP id i222ipke016520; Mon, 1 Mar 2004 21:44:51 -0500 (EST) Received: from taiyo.ja.jpmorgan.com (tkd-fires-02.ja.jpmorgan.com [169.16.62.170]) by mrszip.ny.jpmorgan.com (8.12.1/8.12.1) with ESMTP id i222inDP019359; Mon, 1 Mar 2004 21:44:50 -0500 (EST) Received: from aheading by taiyo.ja.jpmorgan.com with local (Exim 4.22) id 1Axzto-0007HS-PY; Tue, 02 Mar 2004 11:44:48 +0900 Date: Tue, 2 Mar 2004 11:44:48 +0900 From: Anthony Heading To: Wayne Davison Cc: zsh-workers@sunsite.dk Subject: Re: Q: do we want the void* patch? Message-ID: <20040302024448.GA27715@tkd-fires-02.ja.jpmorgan.com> References: <20040301213624.GA18698@blorf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040301213624.GA18698@blorf.net> User-Agent: Mutt/1.5.4i On Mon, Mar 01, 2004 at 01:36:24PM -0800, Wayne Davison wrote: > To revisit my patch in zsh-workers/19445, I didn't get a response to my > last query asking if we want to include it. Was the consensus that we > don't need it? I think that including it would help us to ensure that > the optimizer doesn't over-optimize certain aliased memory locations. Umm, the consensus seemed to be that it made the warnings go away, but that nobody is sure whether it's really fixing a problem. You said in an earlier message: > However, certain casts force the compiler to be less aggressive in > its optimizations (such as (char *) and (void *)). Why do you think that void * is special? Reading http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html which contains this bit from the standard: % 7 An object shall have its stored value accessed only by an lvalue % expression that has one of the following types: {footnote 73} % % a type compatible with the effective type of the object, % % a qualified version of a type compatible with the effective type of % the object, % % a type that is the signed or unsigned type corresponding to the % effective type of the object, % % a type that is the signed or unsigned type corresponding to a % qualified version of the effective type of the object, % % an aggregate or union type that includes one of the aforementioned % types among its members (including, recursively, a member of a % subaggregate or contained union), or % % a character type. Doesn't this suggest one can only use char *? And as Peter said, does the cast really fix the problem or just make it worse? One of the corresponding fixes in glibc - I guess we can assume those guys know what they're doing, looks like - querybuf *buf, *origbuf; + union + { + querybuf *buf; + u_char *ptr; + } buf; + querybuf *origbuf; i.e. using a union type to ensure that aliasing is ok. Didn't seem as simple for them as just casting to void *. Maybe that's what is necessary throughout zsh? Would raise the question of why to bother though - how many compilers won't have an option to turn off the ISO aliasing rules? Perl, for example, uses no-strict-aliasing, so it's not like zsh would be alone. Nor is zsh really in pursuit of fortran's array performance, which is really the whole reason behind this aliasing tedium. And the damage done to code readability in casting things to void * isn't to be taken lightly... Anthony This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Chase & Co., its subsidiaries and affiliates.