From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5991 invoked by alias); 4 Oct 2002 20:20:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5984 invoked from network); 4 Oct 2002 20:20:46 -0000 Received: from unknown (HELO mail-out2.apple.com) (17.254.0.51) by sources.redhat.com with SMTP; 4 Oct 2002 20:20:46 -0000 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g94KKks10003 for ; Fri, 4 Oct 2002 13:20:46 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 4 Oct 2002 13:20:43 -0700 Received: from molly.local. (vpn-scv-x2-210.apple.com [17.219.193.210]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g94KKgV23731; Fri, 4 Oct 2002 13:20:42 -0700 (PDT) Date: Fri, 04 Oct 2002 13:20:00 -0000 Subject: Re: Add rules for ObjC files Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Adam Fedor , gdb-patches@sources.redhat.com To: Stan Shebs From: Klee Dienes In-Reply-To: <3D9DC65C.1070703@apple.com> Message-Id: Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00135.txt.bz2 I definitely agree there's no need to conditionalize them long-term. I just mean there's no way that I know of to check them in with an #ifdef WITH_OBJC for the period where the other changes that they depend on are still being submitted. The objc-lang.y approach has the advantage that the file can be submitted, and optionally enabled or disabled in the Makefile (as I believe Adam was planning to do). On Friday, October 4, 2002, at 12:48 PM, Stan Shebs wrote: > ObjC is supposed to be a strict superset of C, so at least in theory, > extensions don't need to be conditionalized at all, or they can be > disallowed after parsing, if you wanted to have a "strict C mode" > (although I note that the little array@45 extension is always > available, > even though it's not valid C).