[Webkit-unassigned] [Bug 199650] Keyword lookup can use memcmp to get around unaligned load undefined behavior

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=199650

--- Comment #13 from Filip Pizlo <fpizlo at apple.com> ---
(In reply to Saagar Jha from comment #12)
> (In reply to Filip Pizlo from comment #11)
> > (In reply to Saagar Jha from comment #0)
> > 
> > I don't think these constitute good reasons for landing changes to WebKit
> > because:
> > 
> > - We intentionally use unaligned loads in some parts of the code.
> > - We intentionally use reinterpret_casts a lot.
> > - We intentionally do other things that UBSan doesn't agree with.
> > 
> > I don't think we want to change our conventions in regard to those features
> > of the language.
> 
> Note that the way WebKit was using these was not a "feature of the
> language": strictly speaking, the code was invalid C++

Not "was using".  Webkit is using these features in ways that we know are outside what the spec allows, because we don't program to the C++-in-the-spec.  Instead we program in the C++-that-compilers-implement.

> , and this patch
> ensures that the code cannot be miscompiled in the future. From a practical
> standpoint I understand that we already have undefined behavior in our code
> that we will never be able to completely remove (either because we can't
> find it, or because we need to do something that cannot be legally expressed
> in the language)–but I don't see why we should be opposed to changes that
> remove undefined behavior with no regression in execution speed (if
> JavaScript ever adds a long keyword, I think this change might actually
> *improve* performance). Especially if those changes replace a hundred lines
> of specialized and somewhat tedious macros with an easier-to-maintain
> solution ;)

Because all changes carry probability of regression, sometimes regressions that are only discovered long after the change landed.

One of the best ways to ensure code quality is to reject frivolous changes.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190717/ebf45ca4/attachment.html>