Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
Yes I intend to write precisely that, if we ban unsigned types.
However I'm not really convinced that throwing out unsigned types is
the right move.
For instance, one of the optimizations mentioned in the linked video
seems to not mention that using (unsigned!) size_t instead of uint32_t
(like you're sort of supposed to) should also improve code generation
in the same way as using int32_t.
It is, however, super poignant to me that uint32_t-indexing-on-x64 is
pessimal, as that's precisely what our ns* containers (nsTArray) use
for size, /unlike/ their std::vector counterparts, which will be using
the more-optimal size_t.
I'm not saying there's nothing wrong with unsigned types, but rather
than I feel their faults are being overblown, and the arguments
against them feel cherry-picked, which in a language like C++, is easy
to do.
On Thu, Jul 4, 2019 at 4:45 PM Gerald Squelart wrote:
>
> (Glad I started this discussion; thank you Nathan for the enlightening links,
> I need to review all my code now!)
>
> Jeff, maybe what we need is a new value type that advertizes that it's
> unsigned, but doesn't have the unwanted 2^N wrapping (and its effects on
> bug-finding tools and compiler optimizations).
> `class Unsigned { int mValue; /* magic API here */ }` -- feels like unsigned,
> but underneath it's all `int` arithmetics, with optional >=0 assertions.
> Would that help?
>
> Gerald
>
>
> On Friday, July 5, 2019 at 5:35:30 AM UTC+10, Jeff Gilbert wrote:
> > That's what CheckedInt is for, and that's what we use.
> >
> > The problems webgl deals with aren't arithmatic. Arithmatic is easy.
> > (CheckedInt!) Reasoning about constraints is hard.
> >
> > We have some entrypoints where negative values are valid, and many
> > where they are not. It's really nice to have a natural way to document
> > which we expect /at compile time/. Saying "no unsigned types" really
> > throws out the baby with the bathwater for me.
> >
> > On Thu, Jul 4, 2019 at 11:46 AM Botond Ballo wrote:
> > >
> > > On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote:
> > > > It's a huge
> > > > help to have a compile-time constraint that values can't be negative.
> > >
> > > The question is, how useful is that guarantee. Suppose you have some
> > > code that decrements an integer too far, past zero. Instead of having
> > > a -1 you'll have a 4294967295. Is that an improvement? Will it give
> > > the code saner behaviour than the -1?
> > >
> > > Cheers,
> > > Botond
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
(Glad I started this discussion; thank you Nathan for the enlightening links, I
need to review all my code now!)
Jeff, maybe what we need is a new value type that advertizes that it's
unsigned, but doesn't have the unwanted 2^N wrapping (and its effects on
bug-finding tools and compiler optimizations).
`class Unsigned { int mValue; /* magic API here */ }` -- feels like unsigned,
but underneath it's all `int` arithmetics, with optional >=0 assertions.
Would that help?
Gerald
On Friday, July 5, 2019 at 5:35:30 AM UTC+10, Jeff Gilbert wrote:
> That's what CheckedInt is for, and that's what we use.
>
> The problems webgl deals with aren't arithmatic. Arithmatic is easy.
> (CheckedInt!) Reasoning about constraints is hard.
>
> We have some entrypoints where negative values are valid, and many
> where they are not. It's really nice to have a natural way to document
> which we expect /at compile time/. Saying "no unsigned types" really
> throws out the baby with the bathwater for me.
>
> On Thu, Jul 4, 2019 at 11:46 AM Botond Ballo wrote:
> >
> > On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote:
> > > It's a huge
> > > help to have a compile-time constraint that values can't be negative.
> >
> > The question is, how useful is that guarantee. Suppose you have some
> > code that decrements an integer too far, past zero. Instead of having
> > a -1 you'll have a 4294967295. Is that an improvement? Will it give
> > the code saner behaviour than the -1?
> >
> > Cheers,
> > Botond
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On 7/4/19 1:11 PM, Henri Sivonen wrote: I don't _know_, but most like they want to benefit from optimizations based on overflow being UB. It's worth noting that such optimizations can be exploitable if an overflow do occur. See bug 1292443 for an example. Compiling with -fwrapv would fix that, but then you'd lose those optimizations of course. /Mats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
That's what CheckedInt is for, and that's what we use. The problems webgl deals with aren't arithmatic. Arithmatic is easy. (CheckedInt!) Reasoning about constraints is hard. We have some entrypoints where negative values are valid, and many where they are not. It's really nice to have a natural way to document which we expect /at compile time/. Saying "no unsigned types" really throws out the baby with the bathwater for me. On Thu, Jul 4, 2019 at 11:46 AM Botond Ballo wrote: > > On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote: > > It's a huge > > help to have a compile-time constraint that values can't be negative. > > The question is, how useful is that guarantee. Suppose you have some > code that decrements an integer too far, past zero. Instead of having > a -1 you'll have a 4294967295. Is that an improvement? Will it give > the code saner behaviour than the -1? > > Cheers, > Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
Clarification: backfrop-filter will *not* be restricted to secure contexts. On Tue, Jun 25, 2019 at 4:30 PM Connor Brewster wrote: > Summary: The CSS backdrop-filter property allows web authors to specify a > filter to be applied to an element's backdrop. It can be used to create > interesting visual effects that are commonly used in UI design. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178765 > > Standard: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty > > Platform coverage: All platforms using the Gecko rendering engine > (WebRender enabled only) > > Target release: Firefox 71 (WebRender enabled only) > > Preference behind which this will be implemented: > layout.css.backdrop-filter.enabled > > Is this feature enabled by default in sandboxed iframes? Yes > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 > > Do other browser engines implement this? WebKit (since version 9, behind > -webkit- prefix), Blink (since version 47, Behind "Enable Experimental Web > Platform Features" preference) > > web-platform tests: > https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/filter-effects > > Is this feature restricted to secure contexts? Yes > > Connor Brewster > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Heads-up! m-c reformatted on July 5 using Prettier, trees closed
Hey folks, As planned in our announcement a couple weeks ago[0] and according to schedule[1], trees will be closed starting tomorrow morning CET to allow reformatting our JS code using Prettier. This includes m-c, inbound and autoland. Trees will stay closed throughout the day until the format is complete. From our testing, this could be until 10PM CET. Assuming all goes well, there’s 2 important things for you to know: 1. Patches pending for autoland might fail to apply when the trees reopen, and Lando will complain. 2. Patches touching JS code will likely require rebasing. We’ve devised a mechanism to do this automatically for you; expect a followup email about this (and more!) when trees reopen. Victor [0] https://docs.google.com/document/d/1UDERMflocqdszMGhhtxiVhaCTVOHo6jxLsGbt4BR9uw/edit [1] https://docs.google.com/document/d/1qV3aULyhulHsNHvnlbgAxeqlMGnpklUnxmpnY1OovXk/edit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to experiment: Web Share API
> On 1 Jul 2019, at 20:02, Michael de Boer wrote: > > Dale Harvey implemented native share functionality on Desktop before, which > you can access through the meatball menu, inside the urlbar. > So if you’d like to go for parity across platforms, please feel free to reach > out. That’s awesome to hear. Will definitely reach out. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
The LLVM development list has been having a similar discussion, started by a proposal to essentially follow the Google style guide: http://lists.llvm.org/pipermail/llvm-dev/2019-June/132890.html The initial email has links you can follow for more information. I recommend starting here: https://www.youtube.com/watch?v=yG1OZ69H_-o&feature=youtu.be&t=2249 Both for the "why is unsigned arithmetic problematic at scale" (spoiler: you can't check for bad things happening automatically) and an example of "what sort of optimizations are you giving up". Chandler (the speaker above) has a response that is worth reading (noting that objections like yours and otherwise are addressed by the links in the original email): http://lists.llvm.org/pipermail/llvm-dev/2019-June/133023.html -Nathan On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote: > > I really, really like unsigned types, to the point of validating and > casting into unsigned versions for almost all webgl code. It's a huge > help to have a compile-time constraint that values can't be negative. > (Also webgl has implicit integer truncation warnings-as-errors, so we > don't really worry about mixed-signedness) > > If we insist on avoiding standard uint types, I'll be writing uint31_t > wrappers. > > If we're going to recommend against uint types, I would like to see > specific compelling examples of problems with them, not just prose > about "many people say" or "maybe missed optimizations". > > On Thu, Jul 4, 2019 at 8:11 AM Botond Ballo wrote: > > > > On Thu, Jul 4, 2019 at 7:11 AM Henri Sivonen wrote: > > > > Do you happen to know why? Is this due to worries about underflow or > > > > odd behavior on subtraction or something? > > > > > > I don't _know_, but most like they want to benefit from optimizations > > > based on overflow being UB. > > > > My understanding is yes, that's one of the motivations. > > > > Another, as hinted at in Gerald's quote, is that tools like UBSan can > > diagnose and catch signed overflow because it's undefined behaviour. > > They can't really do that for unsigned overflow because, since that's > > defined to wrap, for all the tool knows the code author intended for > > the overflow and wrapping to occur. > > > > Cheers, > > Botond > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On Thu, Jul 4, 2019 at 2:03 PM Jeff Gilbert wrote: > It's a huge > help to have a compile-time constraint that values can't be negative. The question is, how useful is that guarantee. Suppose you have some code that decrements an integer too far, past zero. Instead of having a -1 you'll have a 4294967295. Is that an improvement? Will it give the code saner behaviour than the -1? Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
I really, really like unsigned types, to the point of validating and casting into unsigned versions for almost all webgl code. It's a huge help to have a compile-time constraint that values can't be negative. (Also webgl has implicit integer truncation warnings-as-errors, so we don't really worry about mixed-signedness) If we insist on avoiding standard uint types, I'll be writing uint31_t wrappers. If we're going to recommend against uint types, I would like to see specific compelling examples of problems with them, not just prose about "many people say" or "maybe missed optimizations". On Thu, Jul 4, 2019 at 8:11 AM Botond Ballo wrote: > > On Thu, Jul 4, 2019 at 7:11 AM Henri Sivonen wrote: > > > Do you happen to know why? Is this due to worries about underflow or > > > odd behavior on subtraction or something? > > > > I don't _know_, but most like they want to benefit from optimizations > > based on overflow being UB. > > My understanding is yes, that's one of the motivations. > > Another, as hinted at in Gerald's quote, is that tools like UBSan can > diagnose and catch signed overflow because it's undefined behaviour. > They can't really do that for unsigned overflow because, since that's > defined to wrap, for all the tool knows the code author intended for > the overflow and wrapping to occur. > > Cheers, > Botond > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On Thu, Jul 4, 2019 at 7:11 AM Henri Sivonen wrote: > > Do you happen to know why? Is this due to worries about underflow or > > odd behavior on subtraction or something? > > I don't _know_, but most like they want to benefit from optimizations > based on overflow being UB. My understanding is yes, that's one of the motivations. Another, as hinted at in Gerald's quote, is that tools like UBSan can diagnose and catch signed overflow because it's undefined behaviour. They can't really do that for unsigned overflow because, since that's defined to wrap, for all the tool knows the code author intended for the overflow and wrapping to occur. Cheers, Botond ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On Thursday, July 4, 2019 at 4:53:34 PM UTC+10, Boris Zbarsky wrote: > On 7/4/19 10:11 PM, Gerald Squelart wrote: > > - I found plenty of `unsigned`s around, more than `uint32_t`s. > > How many are in code that predates the ability to use uint32_t, though? I didn't do deeper archaeology, so it's very possible most unsigneds are in old or 3rd party code. But I didn't want to spend more time on this, in case old-timers already had knowledge about it. ;-) > > - Our latest coding style [1] points at Google's, which has a section about > > Integer Types [3], and the basic gist is: Use plain `int` for "not-too-big" > > numbers > > If you can 100% guarantee that they will not be too big, right? > > (In particular, for generation counters I would be somewhat worried > about making such a guarantee.) They did add "use int64_t for "big" numbers". In my own selfish case, it will be once per profiler start/stop. I'm fairly confident a user won't start and stop the profiler a few billion times in a session. :-D But that was not the point of this discussion, sorry for the distraction. > > never use any unsigned type unless you work with bitfields or need 2^N > > overflow (in particular, don't use unsigned for always-positive numbers, > > use signed and assertions instead). > > Do you happen to know why? Is this due to worries about underflow or > odd behavior on subtraction or something? Details in OP[3]. Some juicy bits: "Because of historical accident, the C++ standard also uses unsigned integers to represent the size of containers - many members of the standards body believe this to be a mistake, but it is effectively impossible to fix at this point." "The fact that unsigned arithmetic doesn't model the behavior of a simple integer, but is instead defined by the standard to model modular arithmetic (wrapping around on overflow/underflow), means that a significant class of bugs cannot be diagnosed by the compiler." "Mixing signedness of integer types is responsible for an equally large class of problems." > -Boris g. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Coding style 🙄 : `int` vs `intX_t` vs `unsigned/uintX_t`
On Thu, Jul 4, 2019 at 9:55 AM Boris Zbarsky wrote: > > never use any unsigned type unless you work with bitfields or need 2^N > > overflow (in particular, don't use unsigned for always-positive numbers, > > use signed and assertions instead). > > Do you happen to know why? Is this due to worries about underflow or > odd behavior on subtraction or something? I don't _know_, but most like they want to benefit from optimizations based on overflow being UB. -- Henri Sivonen hsivo...@mozilla.com ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
