(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
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
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
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:
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
> 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
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
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
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
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 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?
- Our latest coding style [1] points at Google's, which has a section about Integer Types
[3], and the basic gist
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
The Google style sounds pretty good to me.
On 04/07/2019 07:11, Gerald Squelart wrote:
> Recently I coded something with a not-very-important slow-changing
> rarely-used positive number: `unsigned mGeneration;`
> My reviewer commented: "Please use a type with an explicit size, such as
>
13 matches
Mail list logo
