From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111652 invoked by alias); 5 Jun 2018 11:38:37 -0000 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 Received: (qmail 111620 invoked by uid 89); 5 Jun 2018 11:38:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:27a478a, H*f:sk:27a478a X-HELO: mail-lf0-f67.google.com Received: from mail-lf0-f67.google.com (HELO mail-lf0-f67.google.com) (209.85.215.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 Jun 2018 11:38:35 +0000 Received: by mail-lf0-f67.google.com with SMTP id n15-v6so3016894lfn.10 for ; Tue, 05 Jun 2018 04:38:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eBpHqalcwlDxW4Sp57ByJeSo8Ing9pg5cOOf8nvA7KU=; b=I0b2oZZ3iPWKVVA0r4Hsn5yucUjG6qYdqf9mQqP6F21AyTgz4FJfc9MH8d2ygYwxeo duoDeTnXbHcXOHHtogQEdnGC9shTsYZtCjCdtntXQc1GczXVnJFiWfDmZ8OyxOgTJHdC Fooer3yIAxrcm6JpAJ/X+C0KOBU3cpgzVe4rtA2dysR2pmr+76SiKhVxfzd63TtsMsec VuAUQdx8MDnLbJiPuS3Viy87LX96560txRaxvf+4Px1KMzP1/gARs8WeObqynyZ4Xn2N qnHBlFCbF5m6AaR9iJu45WNkkXu9aQznQJItqknBYD+bClDYyOL+L3Pxp1OBdH9iZmAQ L0bQ== X-Gm-Message-State: APt69E2nVMKEzCk1YKil+pVuO0OT70bMEcA/sQB5l/aVUFspckvR1lMn QnmPeG6apnOupUJ0oMObGEhKM7aFC/j4Wme0HNw= X-Google-Smtp-Source: ADUXVKINT7DID65jZrzTbl+c4lzoXg3amhel3y04YZqCTTThpfXZEsIsZNHcgVhDEvxJcXanj5CkHsZ3X4n/0avlv64= X-Received: by 2002:a2e:585:: with SMTP id 127-v6mr4111467ljf.28.1528198712639; Tue, 05 Jun 2018 04:38:32 -0700 (PDT) MIME-Version: 1.0 References: <27a478ad-d2d2-7d4e-2dbc-44feae71d10d@gmail.com> In-Reply-To: <27a478ad-d2d2-7d4e-2dbc-44feae71d10d@gmail.com> From: Richard Biener Date: Tue, 05 Jun 2018 11:42:00 -0000 Message-ID: Subject: Re: aliasing between internal zero-length-arrays and other members To: Martin Sebor Cc: GCC Development Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-06/txt/msg00062.txt.bz2 On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor wrote: > > GCC silently (without -Wpedantic) accepts declarations of zero > length arrays that are followed by other members in the same > struct, such as in: > > struct A { char a, b[0], c; }; > > Is it intended that accesses to elements of such arrays that > alias other members be well-defined? The middle-end assumes that fields in a structure do not overlap. For overlaps you have to use a union. In C++ I guess the rule that sizeof() of anything is at least 1 saves you here so IMHO this is a C FE bug and we should probably simply reject non-trailing empty arrays. Note since b has size zero there isn't any real overlap, so ... > In my tests, GCC assumes that neither read nor write accesses > to elements of internal zero-length arrays alias other members, > so assuming those aren't bugs I wonder if the documentation > should be updated to make that clear and a warning added for > such declarations (and perhaps also accesses). > > For example, the test in the following function is eliminated, > implying that GCC assumes that the access to p->b does not modify > p->c, even though with i set to 0 it would: > > void f (struct A *p, int i) > { > int x = p->c; > p->b[i] = 1; > if (x != p->c) > __builtin_abort (); ... your testcase simply invokes undefined behavior by accessing b out of bounds. Richard. > } > > Martin