From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5723 invoked by alias); 19 Nov 2004 01:20:48 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 5713 invoked from network); 19 Nov 2004 01:20:44 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org with SMTP; 19 Nov 2004 01:20:44 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id iAJ1RJCR023020 for ; Thu, 18 Nov 2004 17:27:19 -0800 (PST) Received: from relay1.apple.com (relay1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Thu, 18 Nov 2004 17:21:22 -0800 Received: from [17.219.197.191] ([17.219.197.191]) by relay1.apple.com (8.12.11/8.12.11) with ESMTP id iAJ1KfEf002476; Thu, 18 Nov 2004 17:20:41 -0800 (PST) In-Reply-To: <87zn1eiuy4.fsf@codesourcery.com> References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <852F83A5-39B9-11D9-8317-00039390FFE2@apple.com> <87zn1eiuy4.fsf@codesourcery.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <39B69E96-39C9-11D9-8317-00039390FFE2@apple.com> Content-Transfer-Encoding: 7bit Cc: Matt Austern , gcc mailing list From: Ziemowit Laski Subject: Re: generalized lvalues Date: Fri, 19 Nov 2004 01:38:00 -0000 To: Zack Weinberg X-SW-Source: 2004-11/txt/msg00660.txt.bz2 On 18 Nov 2004, at 15.44, Zack Weinberg wrote: > Matt Austern writes: > >> On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote: >>> The most straighforward -- and intuitive -- way of doing this is >>> precisely via a cast applied to the lvalue, as seen above (with >>> '__strong' expanding to an appropriate attribute). While we have >>> investigated some syntactic alternatives to the cast in light of >>> the impending lvalue cast removal, all of them are counterintuitive >>> in that they fail to express what is being done -- namely, altering >>> the type of a variable for a particular assignment. > > I would like to point out that in *my* arrogant opinion, this use of > lvalue casts is completely *un*intuitive; I would prefer either > declaring the void * with the "this is a GC root" attribute in the > first place, e.g. > > id object; > void *__gcroot ptr; > ... > ptr = object; > > or (if for some reason that is impossible) a builtin function call, > e.g. > > id object; > void *ptr; > ... > __builtin_gc_register(ptr); > ptr = object; Thing is, the code in AppKit and Foundation (our ObjC frameworks) routinely juggles large swaths of uninitialized (and "untyped") memory which is then gradually used up to hold various things, only some of which are pointers to GC-able objects. So statically typing 'ptr' in such cases is out of the question. Of course, in other cases, what you suggest _is_ possible and we do it already: __strong void *ptr; : ptr = object; /* write-barrier call will be generated. */ (Note the consistent way in which '__strong' is used.) The __builtin_gc_register approach would require that the entire GC API be redesigned, and of course would be extremely inefficient, since _every_ assignment in a program would have to go through a write-barrier which would either do something or nothing depending on whether __builtin_gc_register and/or __builtin_gc_unregister has been called. The "cleanest" syntactic approach we could come up with so far is __builtin_objc_gc_strong(ptr) = object; which I suppose we can live with, though the lhs doesn't look too lvaluish this way... :-( --Zem