From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-103235-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17729 invoked by alias); 24 Sep 2004 11:29:43 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 17717 invoked from network); 24 Sep 2004 11:29:42 -0000
Received: from unknown (HELO smtp1.libero.it) (193.70.192.51)
  by sourceware.org with SMTP; 24 Sep 2004 11:29:42 -0000
Received: from localhost (172.16.1.80) by smtp1.libero.it (7.0.027-DD01)
        id 40C7315F0157ECD1; Fri, 24 Sep 2004 13:29:29 +0200
Received: from bagio (151.42.78.220) by smtp1.libero.it (7.0.027-DD01)
        id 40CB2909043C35D2; Fri, 24 Sep 2004 13:29:29 +0200
Message-ID: <02ae01c4a229$cda77880$dc4e2a97@bagio>
From: "Giovanni Bajo" <giovannibajo@libero.it>
To: "Joseph S. Myers" <jsm@polyomino.org.uk>
Cc: "Gabriel Dos Reis" <gdr@cs.tamu.edu>,
	<gcc@gcc.gnu.org>
References: <FA388EC7-0DBB-11D9-8B78-000A95B1F520@apple.com><m3vfe4pk6k.fsf@merlin.cs.tamu.edu> <006d01c4a1dd$ffc60b70$dc4e2a97@bagio> <Pine.LNX.4.61.0409240833430.2844@digraph.polyomino.org.uk>
Subject: Re: attribute data structure rewrite
Date: Fri, 24 Sep 2004 14:45:00 -0000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at libero.it serv2
X-SW-Source: 2004-09/txt/msg01422.txt.bz2

Joseph S. Myers wrote:


>> ----------------------------------------
>> #include <stddef.h>
>> #include <stdio.h>
>>
>> struct A { char foo[10]; };
>>
>> void bar(void) {
>>     int i;
>>     for (i=0;i<10;i++)
>>         printf("%d\n", offsetof(struct A, foo[i]));
>> }
>> --------------------------------------
>>
>> but we used to accept it.  Any idea about its legality? Workarounds?
>
> Compile-time undefined for both C and C++, no diagnostic required; one
> couldn't reasonably be given with the old macro implementations.

Yes. Actually, the old implementation just worked.

> Either diagnose the use of non-integer-constant-expressions in
> offsetof, or permit them but make them cause the result not to be an
> integer constant expression.


I think we currently go with the former. But I believe this to be a regression
in user experience. Using the external + sizeof(i)*blah is ugly. If it was
possible to build the result not being an integer constant expression before
4.0 it would be great. If you want, I can file a bug report to track this.

-- 
Giovanni Bajo