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
(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 optimiz
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
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
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 v
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
> 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 aweso
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://
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 42
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 a
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 y
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
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 worri
13 matches
Mail list logo
