> On Jan 13, 2023, at 11:06 AM, Ryosuke Niwa via webkit-dev 
> <webkit-dev@lists.webkit.org> wrote:
>> On Jan 13, 2023, at 6:39 AM, Darin Adler <da...@apple.com> wrote:
>> I don’t think I can notice these patterns. I would be able to program this 
>> way if I had an analysis tool, but otherwise this simply seems too 
>> complicated.
> Yeah, I agree.
>> I can’t see the types of intermediate values to know if they are CheckedPtr 
>> or RefPtr or raw pointers or whatever. A variation on the first line in 
>> Element::clientLeft is a good example:
>>      document()->updateLayoutIgnorePendingStylesheets();
>> That looks perfectly good to me, nothing makes me think “the result of 
>> document is an unsafe reference to a heap-allocated object and only trivial 
>> functions can be called on that”; I should not need to be an expert on each 
>> function to be able to tell if code is correct or not. How can we choose a 
>> programming style where something simple like that is subtly wrong and 
>> dangerous and requires reviewers to look out for it?
>> I understand that if properly supported by a tool we could adapt to this and 
>> write code a whole new way. Moving to this style without a tool would almost 
>> literally require me to stop working on WebKit because I couldn’t correctly 
>> write or review even a short function.
> I acknowledge that we can’t move to this new model today. So what I’m 
> suggesting is to adopt a smaller scope now: Use smart pointers in all local 
> variables and heap allocated values. This will not be 100% security proof 
> (because of the function return values) but it’s a much better point to get 
> to than where we are now.

Here’s a PR to make the style checker look for raw pointers & references in 
data members: https://github.com/WebKit/WebKit/pull/8907

I suggest we land this PR in 5 business days from now on unless someone objects.

- R. Niwa

webkit-dev mailing list

Reply via email to