(2014/04/07 14:27), Karl Tomlinson wrote:
It is allowed in N3242. I think the relevant sections are
5.2.9 Static cast
Thank you for the pointer.
I found a floating copy of n3242.pdf at the following url.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3242.pdf
I think 7.2 10 is
chiaki ISHIKAWA writes:
I think 7.2 10 is also relevant here.
--- quote ---
An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly. The
value is unchanged if it is in the range of enumeration values of
the enumeration type; otherwise the
On 2014-04-07 6:00 AM, Karl Tomlinson wrote:
chiaki ISHIKAWA writes:
I think 7.2 10 is also relevant here.
--- quote ---
An expression of arithmetic or enumeration type can be converted
to an enumeration type explicitly. The
value is unchanged if it is in the range of enumeration values of
On Fri, 04 Apr 2014 11:03:57 -0400, Zack Weinberg wrote:
On Tue, Apr 1, 2014 at 10:13 PM, Karl Tomlinson mozn...@karlt.net
wrote:
Does WARNINGS_AS_ERRORS make the default:MOZ_CRASH()
unnecessary?
No, because it's possible that the thing you're testing is not
actually a valid enum value,
(2014/04/07 10:16), Karl Tomlinson wrote:
because enumeration types may hold values that don't match any of
their enumerator values.
Is this allowed by C (or C++) specification today?
[Yes, I know the compiler in the past did not care much.]
I thought the stricter warnings of compilers today
chiaki ISHIKAWA writes:
(2014/04/07 10:16), Karl Tomlinson wrote:
because enumeration types may hold values that don't match any of
their enumerator values.
Is this allowed by C (or C++) specification today?
It is allowed in N3242. I think the relevant sections are
5.2.9 Static cast
10 A
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/02/2014 07:37 AM, Aryeh Gregor wrote:
On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg za...@panix.com
wrote:
The downside of turning this on would be that any switch
statements that *deliberately* include only a subset of the
enumerators,
On Tue, Apr 1, 2014 at 5:56 PM, Zack Weinberg za...@panix.com wrote:
The downside of turning this on would be that any switch statements
that *deliberately* include only a subset of the enumerators, plus a
default case, would now have to be expanded to cover all the
enumerators.
If there are
Benoit Jacob jacob.benoi...@gmail.com:
Hi,
Despite a helpful, scary comment above its definition in
mfbt/Assertions.h, MOZ_ASSUME_UNREACHABLE is being misused. Not pointing
fingers to anything specific here, but see
http://dxr.mozilla.org/mozilla-central/search?q=MOZ_ASSUME_UNREACHABLEcase=true
2014-04-01 3:58 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
* Remove jump table bounds checks (See a.cpp; allowing to abuse a jump
table to jump to an arbitrary address);
Just got an idea: we could market this as WebJmp, exposing the jmp
instruction to the Web ?
We could build a
2014-03-28 17:14 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
2014-03-28 16:48 GMT-04:00 L. David Baron dba...@dbaron.org:
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote:
My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE.
It's really handy to have
On 4/1/2014 10:54 AM, Benoit Jacob wrote:
Let's see if we can wrap up this conversation soon now. How about:
MOZ_MAKE_COMPILER_BELIEVE_IS_UNREACHABLE
I counter-propose that we remove the macro entirely. I don't believe
that the potential performance benefits we've identified are worth the
2014-04-01 10:57 GMT-04:00 Benjamin Smedberg benja...@smedbergs.us:
On 4/1/2014 10:54 AM, Benoit Jacob wrote:
Let's see if we can wrap up this conversation soon now. How about:
MOZ_MAKE_COMPILER_BELIEVE_IS_UNREACHABLE
I counter-propose that we remove the macro entirely. I don't
On 4/1/14, 9:57 AM, Benjamin Smedberg wrote:
On 4/1/2014 10:54 AM, Benoit Jacob wrote:
Let's see if we can wrap up this conversation soon now. How about:
MOZ_MAKE_COMPILER_BELIEVE_IS_UNREACHABLE
I counter-propose that we remove the macro entirely. I don't believe
that the potential
On 4/1/14, 10:05 AM, Benoit Jacob wrote:
This macro is especially heavily used in SpiderMonkey. Maybe
SpiderMonkey developers could weigh in on how large are the benefits
brought by UNREACHABLE there?
I don't believe there are any benefits. Those uses of
MOZ_ASSUME_UNREACHABLE are not intended
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This is a bit of a tangent, but: There are a whole bunch of places in
layout, and probably elsewhere, where we have the following catch-22:
if you have a switch statement over the values of an enumeration, gcc
and clang (with -Wall) will warn you
On 04/01/2014 08:56 AM, Zack Weinberg wrote:
The downside of turning this on would be that any switch
statements that *deliberately* include only a subset of the
enumerators, plus a default case, would now have to be expanded to
cover all the enumerators. I would try it and report on how
Jason Orendorff writes:
If the code is truly unreachable, it doesn't matter what we replace it
with. The question is what to do when the impossible occurs. To me,
letting control flow past such a place is just as scary as undefined
behavior.
That depends on the particular code. Often
Zack Weinberg writes:
This is a bit of a tangent, but: There are a whole bunch of places in
layout, and probably elsewhere, where we have the following catch-22:
if you have a switch statement over the values of an enumeration, gcc
and clang (with -Wall) will warn you about enumeration values
Karl Tomlinson writes:
Jason Orendorff writes:
If the code is truly unreachable, it doesn't matter what we replace it
with. The question is what to do when the impossible occurs. To me,
letting control flow past such a place is just as scary as undefined
behavior.
That depends on the
On 4/1/14, 4:37 PM, Karl Tomlinson wrote:
Jason and I spoke on irc and realised that we were talking about 2
slightly different things.
Yep. Filed bug 990764. If someone wants to take, we can continue
discussion there.
-j
___
dev-platform mailing
On 4/1/14 5:37 PM, Karl Tomlinson wrote:
Karl Tomlinson writes:
However, I would like to discourage use of MOZ_CRASH in future
code unless failure to match cases in a switch is really more scary
than crashing.
I think in general we should be willing to make more of our assertions
fatal in
Benjamin Smedberg writes:
I think in general we should be willing to make more of our
assertions fatal in release builds, especially in
non-performance-sensitive code. Of course the choice of assertion
depends on the characteristics of what's being asserted.
Sounds good.
On 4/1/14, 10:22 AM, Daniel Holbert wrote:
So, we have on the order of ~4400 switch statements that would
potentially need expanding to avoid tripping this warning.
clang on OS X reports 1635 -Wswitch-enum warnings (switch on enum not
handling all enum cases). gcc reports 1048
Joshua Cranmer wrote:
MOZ_ASSUME_UNREACHABLE_MARKER tells the compiler that this code and
everything after it can't be reached, so it need do anything. Clang
will delete the code after this branch and decide to not emit any
control flow.
I have found this to be unhelpful when debugging
On 3/28/14, 7:03 PM, Joshua Cranmer wrote:
I included MOZ_ASSUME_UNREACHABLE_MARKER because that macro is the
compiler-specific optimize me intrinsic, which I believe was the
whole point of the original MOZ_ASSUME_UNREACHABLE.
AFAIU, MOZ_ASSUME_UNREACHABLE_MARKER crashes on all Gecko
2014-03-31 15:22 GMT-04:00 Chris Peterson cpeter...@mozilla.com:
On 3/28/14, 7:03 PM, Joshua Cranmer wrote:
I included MOZ_ASSUME_UNREACHABLE_MARKER because that macro is the
compiler-specific optimize me intrinsic, which I believe was the
whole point of the original
Hi,
Despite a helpful, scary comment above its definition in mfbt/Assertions.h,
MOZ_ASSUME_UNREACHABLE is being misused. Not pointing fingers to anything
specific here, but see
http://dxr.mozilla.org/mozilla-central/search?q=MOZ_ASSUME_UNREACHABLEcase=true.
The only reason why one might want
On 3/28/14, 12:25 PM, Benoit Jacob wrote:
Should we give typical code a macro that does what they want and sounds
like what they want? Really, what typical code wants is a no-operation
instead of undefined-behavior; now, that is exactly the same as
MOZ_ASSERT(false, error). Maybe this syntax is
2014-03-28 13:23 GMT-04:00 Chris Peterson cpeter...@mozilla.com:
On 3/28/14, 12:25 PM, Benoit Jacob wrote:
Should we give typical code a macro that does what they want and sounds
like what they want? Really, what typical code wants is a no-operation
instead of undefined-behavior; now, that
On Fri 28 Mar 2014 01:05:34 PM PDT, Benoit Jacob wrote:
2014-03-28 13:23 GMT-04:00 Chris Peterson cpeter...@mozilla.com:
On 3/28/14, 12:25 PM, Benoit Jacob wrote:
Should we give typical code a macro that does what they want and sounds
like what they want? Really, what typical code wants is a
-DEBUG builds.
-Jeff
- Original Message -
From: Steve Fink sf...@mozilla.com
To: Benoit Jacob jacob.benoi...@gmail.com
Cc: Chris Peterson cpeter...@mozilla.com, dev-platform
dev-platform@lists.mozilla.org
Sent: Friday, March 28, 2014 1:20:39 PM
Subject: Re: MOZ_ASSUME_UNREACHABLE is being
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote:
My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE.
It's really handy to have something like MOZ_ASSERT_UNREACHABLE, instead of
having a bunch of MOZ_ASSERT(false, Unreachable.) lines.
Consider
2014-03-28 16:48 GMT-04:00 L. David Baron dba...@dbaron.org:
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote:
My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE.
It's really handy to have something like MOZ_ASSERT_UNREACHABLE, instead
of having a bunch of
On 3/28/14, 4:05 PM, Benoit Jacob wrote:
#define MOZ_CRASH_UNREACHABLE() \
do { \
MOZ_ASSUME_UNREACHABLE_MARKER();\
MOZ_CRASH(MOZ_CRASH_UNREACHABLE); \
} while (0)
MOZ_ASSUME_UNREACHABLE_MARKER tells the compiler feel free to
On 14-03-28 05:14 PM, Benoit Jacob wrote:
2014-03-28 16:48 GMT-04:00 L. David Baron dba...@dbaron.org:
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote:
My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE.
It's really handy to have something like
2014-03-28 17:19 GMT-04:00 Mike Habicher mi...@mozilla.com:
MOZ_UNDEFINED_BEHAVIOUR() ? Undefined behaviour is usually enough to
get C/++ programmers' attention.
I thought about that too; then I remembered that it is only at least a year
_after_ some time at Mozilla working on Gecko, that
2014-03-28 17:14 GMT-04:00 Benoit Jacob jacob.benoi...@gmail.com:
2014-03-28 16:48 GMT-04:00 L. David Baron dba...@dbaron.org:
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote:
My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE.
It's really handy to have
On 3/28/14 5:42 PM, Benoit Jacob wrote:
So... maybe MOZ_MAYBE_PLAY_STARCRAFT?
I'd like to suggest MOZ_IF_REACHED_EXPLODE_COMPUTER.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
39 matches
Mail list logo
