[webkit-dev] Stop Using Raw Pointers & References in New Code

[Ryosuke Niwa]

> On Jan 13, 2023, at 11:06 AM, Ryosuke Niwa via webkit-dev <webkit-dev at lists.webkit.org> wrote:
> 
>> On Jan 13, 2023, at 6:39 AM, Darin Adler <darin at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20230120/1bdf3180/attachment.htm>