On Fri, Jan 27 2023 at 10:52:52 AM -0600, Michael Catanzaro
wrote:
There is probably a relatively high cost compared to WTF::WeakPtr, so
I'd say it should be used only when it provides valuable safety (e.g.
in member variables) rather than spammed (e.g. in local variables).
Another good use
On Tue, Jan 24 2023 at 02:53:42 PM -0600, Michael Catanzaro
wrote:
E.g. for GObjects, we could write GWeakPtr, but this would not be
very ergonomic, and it won't work for arbitrary types.
So Carlos Garcia added this in https://commits.webkit.org/259482@main.
There is a downside to GWeakPtr:
On Wed, Jan 25, 2023 at 5:54 AM Michael Catanzaro via webkit-dev <
webkit-dev@lists.webkit.org> wrote:
>
> Thinking about this more, I'm not sure this plan works for WeakPtrs?
> Say we have:
>
> WeakPtr f = /* initialized somehow */;
> if (Foo* f = f.get())
> {
> // do something
> }
>
> Then we
On Tue, Jan 24 2023 at 11:33:45 AM -0800, Ryosuke Niwa via webkit-dev
wrote:
That’s also the semantics of Ref/RefPtr in WebKit. But we’re
expanding the use of Ref/RefPtr to be beyond just owners for memory
safety. I don’t see how the situation is any different with
GRefPtr/GUniquePtr. If an
> On Jan 24, 2023, at 5:30 AM, Alicia Boya García via webkit-dev
> wrote:
>
> On 12/01/2023 06.21, Ryosuke Niwa via webkit-dev wrote:
>> I suggest we stop using raw pointers and references in any local or heap
>> stored variable.
> I don't think this is feasible for code using non-WebKit
Hm, I see you're right because CheckedRef/CheckedPtr are intrusive
pointers that require modification of the type to be pointed to, so
they are not going to work in general as they cannot be used for types
that do not inherit from CanMakeCheckedRef/CanMakeCheckedPtr.
On 12/01/2023 06.21, Ryosuke Niwa via webkit-dev wrote:
I suggest we *stop using raw pointers and references in any local or
heap stored variable*.
I don't think this is feasible for code using non-WebKit libraries, and
would expect it to not apply to such cases.
For instance, many GLib and
Is the idea that a checker failure should block landing a patch, or just that
it should start a conversation with your patch reviewer about why this case is
an exception?
Maybe the ’should’ clause in the error message could clarify.
In general, I do think it’s helpful to flag any new raw
On Fri, Jan 20 2023 at 06:15:38 PM -0800, Ryosuke Niwa via webkit-dev
wrote:
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.
> On Jan 13, 2023, at 11:06 AM, Ryosuke Niwa via webkit-dev
> wrote:
>
>> On Jan 13, 2023, at 6:39 AM, Darin Adler 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.
>
> On Jan 13, 2023, at 6:39 AM, Darin Adler 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
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. 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
> On Jan 12, 2023, at 9:05 PM, Ryosuke Niwa via webkit-dev
> wrote:
>
>
>> On Jan 12, 2023, at 8:37 PM, Darin Adler wrote:
>>
>>> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote:
>>>
>>> One alternative is to make bar() return RefPtr although that would be a bit
>>> heavy handed in the
> On Jan 12, 2023, at 8:37 PM, Darin Adler wrote:
>
>> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote:
>>
>> One alternative is to make bar() return RefPtr although that would be a bit
>> heavy handed in the case of trivial function calls like this:
>> document().frame()->ownerElement()
>
> On Jan 12, 2023, at 9:35 PM, Ryosuke Niwa wrote:
>
> One alternative is to make bar() return RefPtr although that would be a bit
> heavy handed in the case of trivial function calls like this:
> document().frame()->ownerElement()
I don’t quite follow. You just said that all arguments
> On Jan 12, 2023, at 6:50 PM, Michael Catanzaro wrote:
>
> On Thu, Jan 12 2023 at 12:35:09 PM -0800, Ryosuke Niwa via webkit-dev
> wrote:
>> So… instead of:
>> foo(bar());
>> do:
>> foo(RefPtr { bar() }.get());
>
> What's the value of creating a temporary RefPtr just to get at the
On Thu, Jan 12 2023 at 12:35:09 PM -0800, Ryosuke Niwa via webkit-dev
wrote:
So… instead of:
foo(bar());
do:
foo(RefPtr { bar() }.get());
What's the value of creating a temporary RefPtr just to get at the
underlying raw pointer? Isn't this overkill?
> On Jan 12, 2023, at 1:27 PM, Darin Adler wrote:
>
>> On Jan 12, 2023, at 3:35 PM, Ryosuke Niwa via webkit-dev
>> wrote:
>>
>>> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote:
>>>
On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev
wrote:
assuming every local
> On Jan 12, 2023, at 3:35 PM, Ryosuke Niwa via webkit-dev
> wrote:
>
>> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote:
>>
>>> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev
>>> wrote:
>>>
>>> assuming every local variable / variable in stack is stored in a smart
>>> pointer,
> On Jan 12, 2023, at 6:13 AM, Darin Adler wrote:
>
>> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev
>> wrote:
>>
>> assuming every local variable / variable in stack is stored in a smart
>> pointer, function arguments are safe to be raw pointers / references via
>> transitive
> On Jan 12, 2023, at 12:21 AM, Ryosuke Niwa via webkit-dev
> wrote:
>
> assuming every local variable / variable in stack is stored in a smart
> pointer, function arguments are safe to be raw pointers / references via
> transitive property
What about the case where the function argument is
21 matches
Mail list logo
