On Wednesday, July 10, 2019 at 9:12:23 AM UTC+10, Bobby Holley wrote:
> On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey wrote:
>
> > On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote:
> > > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart
> > > wrote:
> > >
> > > > Thank you all for some
On Tue, Jul 9, 2019 at 3:23 PM Mike Hommey wrote:
> On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote:
> > On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart
> > wrote:
> >
> > > Thank you all for some very interesting discussions so far.
> > >
> > > Even if we don't take blanket steps
On Tue, Jul 09, 2019 at 10:39:37AM -0400, Ehsan Akhgari wrote:
> On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart
> wrote:
>
> > Thank you all for some very interesting discussions so far.
> >
> > Even if we don't take blanket steps to avoid unsigned types in
> > non-bitfield/modulo cases (as
On Mon, Jul 8, 2019 at 11:00 PM Gerald Squelart
wrote:
> Thank you all for some very interesting discussions so far.
>
> Even if we don't take blanket steps to avoid unsigned types in
> non-bitfield/modulo cases (as suggested by our newly-adopted Google style),
> at least hopefully we're now
Thank you all for some very interesting discussions so far.
Even if we don't take blanket steps to avoid unsigned types in
non-bitfield/modulo cases (as suggested by our newly-adopted Google style), at
least hopefully we're now aware of their subtleties, and we can be more careful
and
dom/canvas has enabled -Werror=implicit-int-conversion since 68! :)
https://bugzilla.mozilla.org/show_bug.cgi?id=1540357
On Fri, Jul 5, 2019 at 11:15 AM Chris Peterson wrote:
>
> On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote:
> >> FWIW once in a while I have come across bugs caused by truncation
Hello!
Just wish to chime in with my 2c... Would the proposed shift towards
signed types only be for larger values (eg, >= 32 bits)?
Audio and rendering code would still require using unsigned types,
especially when packed into buffers. (eg, 8-bit unsigned color components,
32-bit packed RGBA
On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote:
FWIW once in a while I have come across bugs caused by truncation of
integers where someone picked a specific size that was too small also,
e.g.
storing an offset into a text node in a 16-bit integer. I think that's
maybe something that's hiding
On 05/07/2019 17:36, Ehsan Akhgari wrote:
On Thu, Jul 4, 2019 at 8:05 AM Gerald Squelart
wrote:
- 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
On Thu, Jul 4, 2019 at 8:05 AM Gerald Squelart
wrote:
> > > - 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?
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> 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.
>
Note that such a class, if it performs assertions, is actually completely
different
On Fri, Jul 5, 2019 at 1:28 PM Nathan Froyd wrote:
>
> On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> > 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
On Fri, Jul 5, 2019 at 2:48 AM Jeff Gilbert wrote:
> 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.
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
(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 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'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
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:
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
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 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
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
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
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
>
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
uint32_t. (General mozilla style; you don't see a bare "unsigned" around much)"
I had never heard of
26 matches
Mail list logo
