From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28196 invoked by alias); 24 May 2009 01:17:10 -0000 Received: (qmail 28185 invoked by uid 22791); 24 May 2009 01:17:10 -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 01:17:05 +0000 Received: by ewy1 with SMTP id 1so2707574ewy.8 for ; Sat, 23 May 2009 18:17:02 -0700 (PDT) Received: by 10.211.166.2 with SMTP id t2mr2930957ebo.8.1243127822611; Sat, 23 May 2009 18:17:02 -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 10sm295750eyz.21.2009.05.23.18.17.01 (version=SSLv3 cipher=RC4-MD5); Sat, 23 May 2009 18:17:01 -0700 (PDT) Message-ID: <4A18A2C8.2020204@gmail.com> Date: Sun, 24 May 2009 09:21:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Dave Korn CC: "gcc@gcc.gnu.org" Subject: Re: What does zero-length array mean at file scope? References: <4A189BCD.1090707@gmail.com> In-Reply-To: <4A189BCD.1090707@gmail.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/msg00586.txt.bz2 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! Owing to lack of support for alignment of common symbols in PE, we've been rounding all sizes up to a multiple of 16 until now, including zero, which has hidden this problem from arising. In the patch I just posted at http://gcc.gnu.org/ml/gcc-patches/2009-05/msg01528.html we can now align common symbols, so we don't round any more - and thus get an actual zero-sized symbol definition passed to the assembler for the first time. I do think we probably ought to be erroring about this on both platforms, shouldn't we? I can always hack the output routine to (for example) use one unit of the alignment size as the minimum to work around this problem and let the testcase run, but I wonder if a warning is getting lost somewhere owing to array->pointer flattening? cheers, DaveK