Re: [webkit-dev] New status field required for feature flags
> On Jan 10, 2023, at 06:39, Michael Catanzaro wrote: > > Different default values for different ports is unavoidable; there are many > many other examples besides PDF.js where ports just need to be different. But > I think it's OK for the status field to be the same on all platforms. Just > set the status value to whatever works best for Apple. The status field could > control the *default* default value, which you can feature on > https://webkit.org/status/, but ports should still be able to override it if > needed. Sound good? > > By the way, while this seems like a good cleanup to me, I see there are > really a *lot* of statuses defined. I don't think I'd be able to understand > which one is correct to use for a feature unless I have that table explaining > what each one does in front of me. I wonder if they're all truly required. I’m adding some inline documentation to UnifiedWebPreferences.yaml in https://github.com/WebKit/WebKit/pull/8549, to help clarify things. Feedback appreciated! > On Jan 10, 2023, at 07:31, Jean-Yves Avenard > wrote: > > Hi. > > What status should be used for: > "Enabled by default on most platforms except those we’ve decided not to > support or if a local system dependency can’t be met but feature is still > ready for general use, but UI to toggle the feature remains to support > debugging, A/B testing." That should be an acceptable use for ‘stable’. With this in mind, Brent and I updated the definition of ’stable’ to relax it a bit: ON by default. Some platforms may deviate from default behavior due to # support or needed dependencies. > That defaultValue could be ignored in the future seems a regression and > doesn’t address some existing use cases. While we don’t have any enforcement of the defaults now (i.e. the the feature defaults are only advisory, and whatever is in defaultValue is used), I’d like to get us to a point where the defaults are widely used. The only time we should need to deviate is for platform-specific considerations like these. If and when we get there, I’ll make sure the defaultValue is *not* silently ignored by the code generator :) Elliott ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
> 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 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. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Stop Using Raw Pointers & References in New Code
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 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. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
