Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: 5.8: LTO exposes some new issues
- X-seq: zsh-workers 46277
- From: Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx>
- To: Roman Perepelitsa <roman.perepelitsa@xxxxxxxxx>
- Subject: Re: 5.8: LTO exposes some new issues
- Date: Tue, 28 Jul 2020 11:19:55 +0000
- Cc: Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>, Zsh hackers list <zsh-workers@xxxxxxx>
- In-reply-to: <CAN=4vMp0GP=JJrfP=N6q7s_yCXp-_LMJBL1dC8Kd2weMNPvm0A@mail.gmail.com>
- List-help: <mailto:zsh-workers-help@zsh.org>
- List-id: Zsh Workers List <zsh-workers.zsh.org>
- List-post: <mailto:zsh-workers@zsh.org>
- List-unsubscribe: <mailto:zsh-workers-unsubscribe@zsh.org>
- Mailing-list: contact zsh-workers-help@xxxxxxx; run by ezmlm
- 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>
- Sender: zsh-workers@xxxxxxx
Roman Perepelitsa wrote on Tue, 28 Jul 2020 12:52 +0200:
> On Tue, Jul 28, 2020 at 10:26 AM Peter Stephenson
> <p.w.stephenson@xxxxxxxxxxxx> wrote:
> >
> > > On 28 July 2020 at 08:53 Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > It's clearly correct, but as written, the patch loses the distinction
> > > that these members are private to hashtable.c and should not be accessed
> > > by other parts of the code. Could you address that, please? If
> > > there's an easy way to have the compiler enforce this restriction,
> > > great; else, we can at least add a comment.
> >
> > One way is to have a "struct { ... } private" substructure,
> > which it makes it clear what's going on within the code (though comments
> > are obviously useful, too).
>
> 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.
So we need either a comment at the definition of the struct type that
says nobody should allocate/duplicate/assign such structs directly, but
call newhashtable() instead, or a solution that doesn't involve casts,
such as Peter's proposal.
Cheers,
Daniel
Messages sorted by:
Reverse Date,
Date,
Thread,
Author