From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13187 invoked by alias); 24 May 2009 09:47:58 -0000 Received: (qmail 13177 invoked by uid 22791); 24 May 2009 09:47:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f157.google.com (HELO mail-ew0-f157.google.com) (209.85.219.157) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 24 May 2009 09:47:52 +0000 Received: by ewy1 with SMTP id 1so2799995ewy.8 for ; Sun, 24 May 2009 02:47:49 -0700 (PDT) Received: by 10.211.166.2 with SMTP id t2mr3331903ebo.8.1243158469541; Sun, 24 May 2009 02:47:49 -0700 (PDT) Received: from ?192.168.2.99? (cpc2-cmbg8-0-0-cust61.cmbg.cable.ntl.com [82.6.108.62]) by mx.google.com with ESMTPS id 5sm1324366eyh.10.2009.05.24.02.47.48 (version=SSLv3 cipher=RC4-MD5); Sun, 24 May 2009 02:47:49 -0700 (PDT) Message-ID: <4A191A80.9010001@gmail.com> Date: Sun, 24 May 2009 10:57:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Andrew Haley CC: Dave Korn , "gcc@gcc.gnu.org" Subject: Re: What does zero-length array mean at file scope? References: <4A189BCD.1090707@gmail.com> <4A18A2C8.2020204@gmail.com> <4A18B11A.6080505@gmail.com> <4A1912AC.6080505@redhat.com> In-Reply-To: <4A1912AC.6080505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00592.txt.bz2 Andrew Haley wrote: > Dave Korn wrote: >> Dave Korn wrote: >>> Dave Korn wrote: >>> >>>> ELF GAS/LD seem happy enough when presented with a ".comm foo,0" >>>> directive, but PE does rather literally what you asked, and gives you >>>> no data object, leading to i0 in the above being an undefined >>>> reference at link time. >>> After a bit further digging, it turns out that this is because PE uses >>> the same representation for an external symbol as would represent a >>> common of size 0, so if you define such a common, it magically becomes >>> an undefined external symbol instead! > > I don't see what the big deal is here: just allocate one byte to a > statically- allocated zero-length array. The "big deal" is that this is blatantly and trivially invalid code, and we silently accept it and generate nonsensical assembler output without the least hint of any kind of a diagnostic. " 6.7.5.2 Array declarators Constraints 1 In addition to optional type qualifiers and the keyword static, the [ and ] may delimit an expression or *. If they delimit an expression (which specifies the size of an array), the expression shall have an integer type. If the expression is a constant expression, it shall have a value greater than zero. " > Sure, but in that case it's clearly the user's fault: they're writing > beyond the bounds of an array. But how, as a user, would you attempt to write /within/ the bounds of such an array? Exactly. So why should we let the user create this meaningless construct in the first place? cheers, DaveK