From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.0 required=5.0 tests=DKIM_ADSP_CUSTOM_MED,
	FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 14586 invoked from network); 28 Jul 2020 11:32:39 -0000
Received: from ns1.primenet.com.au (HELO primenet.com.au) (203.24.36.2)
  by inbox.vuxu.org with ESMTPUTF8; 28 Jul 2020 11:32:39 -0000
Received: (qmail 12975 invoked by alias); 28 Jul 2020 11:32:31 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
List-Unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
Sender: zsh-workers@zsh.org
X-Seq: 46278
Received: (qmail 3375 invoked by uid 1010); 28 Jul 2020 11:32:31 -0000
X-Qmail-Scanner-Diagnostics: from mail-il1-f174.google.com by f.primenet.com.au (envelope-from <roman.perepelitsa@gmail.com>, uid 7791) with qmail-scanner-2.11 
 (clamdscan: 0.102.3/25884. spamassassin: 3.4.4.  
 Clear:RC:0(209.85.166.174):SA:0(-2.0/5.0):. 
 Processed in 1.32222 secs); 28 Jul 2020 11:32:31 -0000
X-Envelope-From: roman.perepelitsa@gmail.com
X-Qmail-Scanner-Mime-Attachments: |
X-Qmail-Scanner-Zip-Files: |
Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.166.174 as permitted sender)
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=eHRFoV6DifrcdUorq5KXT5zlPagsTKuun8v8QVB1dQI=;
        b=E+60Ru/SpEQlkUIa7iDby5Uam68utG/nxantfKBm64fg9jUx2egIkK7d+EfQHjWgPw
         vDMmdHevQMdFnIPxmx+KZXVaRsQD+IiBH+klXvNC3T/IIURAp9PGjwYSkYi6vJ7/2QwF
         qPjevozqPIpKrDt7nT9AnrmGBNfa7OIveuI2ibS5r6N9rNrmijHctb9Emn78bfXp8QOi
         DOSaZMIT0KFuvrupRiiQ9u7z3Z0F90dg4XM6wjRK8pc2Tb+dNSLSQRF5uwq0lGnJf2BN
         9UocvWbN7iVGzVFcILjiAO/SueZSps0zeNFyWXsK+IMQJG7KjZ7c65WvWLZjDI7BmIyJ
         1PTw==
X-Gm-Message-State: AOAM532BYLuv/9brrUc8rjJd2ju4RpS+Rhy6xL59YPljxXOiHZcnAAgD
	Vm8gjv+RPPCzwpa4wTKjPfHlYMqWUZtJXwC19rs=
X-Google-Smtp-Source: ABdhPJxZElJo3PPd7bGuamtSDurxM+dhVPmcUG8C6E+pWuvYRqjuLoaxeVoKTE1/4b7ggl74+cf08lq95q9ecNauaRA=
X-Received: by 2002:a92:6e05:: with SMTP id j5mr7101246ilc.169.1595935916503;
 Tue, 28 Jul 2020 04:31:56 -0700 (PDT)
MIME-Version: 1.0
References: <CABB28CwZXqp6AEr1Gnk_VFBOqeFNhPVnUnTJGTae=ePkqeMFkw@mail.gmail.com>
 <ca26b639-1878-4e72-9fad-a4037912038a@www.fastmail.com> <CAH+w=7aCiU6ZAeh1JwRg+b+A=WrFTz4_8st9_UXOy_VYZ9M77Q@mail.gmail.com>
 <CABB28CxSD5w-SY-iCVYuQ4kJfBpNJOWhpk4HOrS1DNPfMVztgw@mail.gmail.com>
 <CAH+w=7Z0oDO18u7uRVoOhjG0-0ydvi65zt2mMHD_wb636C9F1w@mail.gmail.com>
 <35bf1c7b-163f-4baf-9d5a-c1d7e72459ec@www.fastmail.com> <CABB28Cxo3HAvDf-MhpRyNVuK_TjNXpT+nhfWsSax=BK8+RTUhQ@mail.gmail.com>
 <CAN=4vMoe4z=QqGK6FOxqo4FBYXj7oOU2NQJNk58iqtXR9agk1Q@mail.gmail.com>
 <CAN=4vMpxGgZTcvhmqjzvNFvybqiJTqjTZvs+Ky17F9=7OxU0QA@mail.gmail.com>
 <20200728075343.2cfb1ebf@tarpaulin.shahaf.local2> <727383568.664238.1595924724485@mail2.virginmedia.com>
 <CAN=4vMp0GP=JJrfP=N6q7s_yCXp-_LMJBL1dC8Kd2weMNPvm0A@mail.gmail.com> <20200728111956.21617dde@tarpaulin.shahaf.local2>
In-Reply-To: <20200728111956.21617dde@tarpaulin.shahaf.local2>
From: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Date: Tue, 28 Jul 2020 13:31:45 +0200
Message-ID: <CAN=4vMrsVn+2vZqrzRwRk11iMTRoxEiEZqxCYTy=WY+oo4kLiw@mail.gmail.com>
Subject: Re: 5.8: LTO exposes some new issues
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Peter Stephenson <p.w.stephenson@ntlworld.com>, Zsh hackers list <zsh-workers@zsh.org>
Content-Type: text/plain; charset="UTF-8"

On Tue, Jul 28, 2020 at 1:20 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Roman Perepelitsa wrote on Tue, 28 Jul 2020 12:52 +0200:
> >
> > How about this? The diff is a bit larger but the code is fairly
> > straightforward. Only hashtable.c has access to internal fields, just
> > like before the patch.
> >
> > In a nutshell, struct hashtable has only public data members. Within
> > hashtable.c there is struct hashtableimpl, which has struct hashtable
> > as the first data member. C allows casting a pointer to a struct to a
> > pointer to its first data member and back without violating aliasing
> > rules. Thus hashtable.c can cast struct hashtable* to struct
> > hashtableimpl* in order to get access to internal fields.
>
> Thanks, that addresses the previous point, but unfortunately it creates
> another problem: people who read the .h file are liable to declare
> local variables of type 'struct hashtable', or memcpy() them around,
> and in either case, once such a variable gets to hashtable.c and the
> private members are accessed, we'll get out-of-bounds reads.

This problem exists in the current version of the code, too. The patch
addresses one problem -- it removes undefined behavior due to ODR
violation. If you want, I can extend the patch so that it also
addresses the second problem you've identified although it might be
betted done in a separate patch given that it's independent from the
first.

Roman.