In order to provide more solid technical background for this conversation,
I've studied a bit the practical effect of __builtin_unreachable on some
test programs, in GCC 4.6 and in Clang 3.4.
All my files are here,
https://github.com/bjacob/builtin-unreachable-study
The results are in the
Hi,
We have a property in greprefs.js layout.css.dpi by which we can control
pixel size , but this doesn't work in Windows. There is another property
layout.css.devPixelsPerPx which control font size in Windows but this needs
to be modified each time as per system DPI. I need to show font size
On 1/4/14 13:05, bhargava.animes...@gmail.com wrote:
Hi,
We have a property in greprefs.js layout.css.dpi by which we can
control pixel size , but this doesn't work in Windows. There is
another property layout.css.devPixelsPerPx which control font size
in Windows but this needs to be modified
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
While working on https://bugzilla.mozilla.org/show_bug.cgi?id=980317 ,
I discovered that support for mozilla::NullptrT and nullptr is worse
on B2G ICS emulator than on other platforms, including B2G JB and
Android ICS. See
https://tbpl.mozilla.org/php/getParsedLog.php?id=35791355tree=Tryfull=1
for
On 4/1/2014 8:42 AM, Henri Sivonen wrote:
This makes me wonder if B2G ICS emulator uses a nullptr-wise backwards
compiler / compiler settings by accident. Can it be changed to use a
compiler / compiler settings similar to B2G JB and Android ICS?
B2G ICS uses gcc 4.4, IIRC. All of the Android
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
Hi!
As you want to get rid of all plugins (NPAPI), you say: If there are
plugin features which are not available in the web platform, we encourage
developers to post their use cases to mozilla.dev.platform project list”.
https://developer.mozilla.org/en-US/Add-ons/Plugins
We have such a feature:
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 Tue, Apr 01, 2014 at 09:47:15AM -0500, Joshua Cranmer ? wrote:
On 4/1/2014 8:42 AM, Henri Sivonen wrote:
This makes me wonder if B2G ICS emulator uses a nullptr-wise backwards
compiler / compiler settings by accident. Can it be changed to use a
compiler / compiler settings similar to B2G JB
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
Hi!
Well, I think adding an API to query directly whether an application is
installed could be a privacy risk. This is why Microsoft added this API to
obscure this information to the web page and just call either the success
or failure callback.
In Citrix, we use this API on IE 11 / Win 8 to
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
Wow, okay. A lot to address here.
The primary instigator of this migrating of user repositories off to external
services came from when we were (and still are) crunched for disk space after
restructuring our Mercurial infrastructure to use local disks.
We did this for several reasons:
* An
FYI: (bcc: release@, sheriffs@)
Original Message
Subject:[Planned Maintenance Notification] 4/5 Tree Closing
Maintenance Window
Date: Tue, 01 Apr 2014 20:32:56 -
Short Summary:
Mozilla IT will have a tree closing maintenance window on Saturday, 4/5, from
0700
The subject of this post is intentionally chosen to make you want to read
this. :-)
The summary is that I think the mozilla::Atomic API which is modeled after
std::atomic is harmful in that it makes it very non-obvious that you're
dealing with atomic integers. Basically the existing interface
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
On 04/01/2014 09:44 AM, Trevor Saunders wrote:
b2g jb using gcc 4.7 was what I guessed as well, but
http://ftp.mozilla.org/pub/mozilla.org/b2g/tinderbox-builds/mozilla-central-hamachi/1396314004/b2g_mozilla-central_hamachi_dep-bm72-build1-build10.txt.gz
seems to provide some evidence to the
I've got some outside experience with std::atomic so make of it what you
will :)
How often are you touching atomic variables directly? In my experience with
a similar thread safe inline ref count and smart pointer system to
Mozilla's (using std::atomic for the ref count), there's been no
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 2014-04-01, at 15:15, Rob Arnold tell...@gmail.com wrote:
the similarity to a non-atomic integer type actually has prompted me to
have a (temporary) false sense of thread unsafety, rather than a false
sense of thread safety.
That was my impression too. I usually find that I have to chase
On 04/01/2014 02:32 PM, Ehsan Akhgari wrote:
What do people feel about my proposal? Do you think it improves writing
and reviewing thread safe code to be less error prone?
As I said in the bug, not particularly. I don't think you can program with
atomics in any sort of brain-off way, and I
2014-04-01 18:40 GMT-04:00 Jeff Walden jwalden+...@mit.edu:
On 04/01/2014 02:32 PM, Ehsan Akhgari wrote:
What do people feel about my proposal? Do you think it improves writing
and reviewing thread safe code to be less error prone?
As I said in the bug, not particularly. I don't think
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
On 2014-04-01, 6:59 PM, Benoit Jacob wrote:
2014-04-01 18:40 GMT-04:00 Jeff Walden jwalden+...@mit.edu:
On 04/01/2014 02:32 PM, Ehsan Akhgari wrote:
What do people feel about my proposal? Do you think it improves writing
and reviewing thread safe code to be less error prone?
As I said in
On 2014-04-01, at 16:17, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Just to clarify my position a bit more, I think criticizing my position by
pretending that I'm advocating for a brain-off way of programming with
atomics is a bit contrived. I definitely understand that atomics require
On 2014-04-01, 6:15 PM, Rob Arnold wrote:
I've got some outside experience with std::atomic so make of it what you
will :)
How often are you touching atomic variables directly? In my experience
with a similar thread safe inline ref count and smart pointer system to
Mozilla's (using std::atomic
On 2014-04-01, 6:03 PM, Jeff Walden wrote:
On 04/01/2014 09:44 AM, Trevor Saunders wrote:
b2g jb using gcc 4.7 was what I guessed as well, but
On 2014-04-01, 7:32 PM, Martin Thomson wrote:
On 2014-04-01, at 16:17, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
Just to clarify my position a bit more, I think criticizing my position by
pretending that I'm advocating for a brain-off way of programming with atomics
is a bit contrived.
On Tue, Apr 01, 2014 at 05:32:12PM -0400, Ehsan Akhgari wrote:
The subject of this post is intentionally chosen to make you want to read
this. :-)
The summary is that I think the mozilla::Atomic API which is modeled after
std::atomic is harmful in that it makes it very non-obvious that
On 2014-04-01, at 16:48, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:
My contention is that it is obvious enough by looking at (a) to tell that
mRefCnt is an atomic value which should be handled with the necessary care,
so the pattern (b) would be caught either at code writing time or at
On 2014-04-01, 7:58 PM, Mike Hommey wrote:
On Tue, Apr 01, 2014 at 05:32:12PM -0400, Ehsan Akhgari wrote:
The subject of this post is intentionally chosen to make you want to read
this. :-)
The summary is that I think the mozilla::Atomic API which is modeled after
std::atomic is harmful in
On Tue, Apr 01, 2014 at 08:34:01PM -0400, Ehsan Akhgari wrote:
On 2014-04-01, 7:58 PM, Mike Hommey wrote:
On Tue, Apr 01, 2014 at 05:32:12PM -0400, Ehsan Akhgari wrote:
The subject of this post is intentionally chosen to make you want to read
this. :-)
The summary is that I think the
On Wednesday 2014-04-02 12:50 +0900, Mike Hommey wrote:
On Tue, Apr 01, 2014 at 08:34:01PM -0400, Ehsan Akhgari wrote:
That is the code after I changed it. :-) Here is the original patch which
introduced this bug:
https://bug935778.bugzilla.mozilla.org/attachment.cgi?id=8385072 The
On 4/1/2014 4:32 PM, Ehsan Akhgari wrote:
So, over in bug 987887 I'm proposing to remove all of the methods on
mozilla::Atomic except for copy construction and assignment and replace
them with global functions that can operate on the atomic type. atomic
has a number of global functions that can
On Wed, Apr 2, 2014 at 12:12 PM, L. David Baron dba...@dbaron.org wrote:
The issue here is whether this particular way of writing threadsafe
code leads people modifying that code to make mistakes because they
don't even notice that it's threadsafe code.
I completely agree. And because using
On Wed, Apr 2, 2014 at 12:11 AM, Joshua Cranmer pidgeo...@gmail.comwrote:
My original design for mozilla::Atomic was meant to avoid what I saw as
the biggest footgun: you cannot misuse mozilla::Atomic in such a way that
you combine atomic and non-atomic accesses on a single variable. You
Hi,
When I added code with a function udev_monitor_new_from_socket(),
the Nightly stops executing everything while this function returns
an error fd.
I strongly suspect this happens due to the permission issue while Nightly does
not allow me to gain root privileges.
However, this is necessary
45 matches
Mail list logo
