Re: Non-UTF-8 file paths on Gtk platforms
Given that everyone else working in this area agrees that UTF-8 file paths are the Right Thing and wants to desupport legacy encodings, I would now vote for suggestion 1 (contra what I said last year in bug 960957, which amounts to a variation on your suggestion 2). However, I think it might be a good idea to add some minimal telemetry so we know about it if and when users encounter non-UTF-8 paths and in what context. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: WOFF2 webfont format
On 2014-10-03 4:37 AM, Jonathan Kew wrote: it seems we fetch fonts using Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 which doesn't look even remotely sensible. Agree, but note that there are no official MIME types for most font formats. (I *think* application/font-woff did get registered for WOFF1.) Lots of people have just made up MIME types, including e.g. application/x-ttf, application/ttf, font/ttf (inventing a whole category!) and so on. I'm not aware of any significant changes in this area since I wrote https://www.owlfolio.org/htmletc/strawman-mime-type-for-fonts/ back in 2011. As described in that post, I continue to think that Accept: application/font plus client-side selection of URL based on format() is the Right Thing. I just filed bug 1077312. However, I don't think this needs to actually block the implementation of WOFF2 support. Also agree here. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
On 2014-08-27 1:53 AM, Nicholas Nethercote wrote: On Wed, Aug 27, 2014 at 5:49 AM, Zack Weinberg za...@panix.com wrote: Seems to me there might be value in applying video controls-style controls to animated imgs *in general* -- not just for mobile. That's a great idea! Looks like that's https://bugzilla.mozilla.org/show_bug.cgi?id=560084 . ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PSA: ./mach build subdirectory doesn't work reliably any longer
On 2014-08-27 12:29 PM, Steve Fink wrote: Maybe it's just me, but I'm having a lot of trouble following this thread. Can someone spell out exactly what use cases we're talking about here? Because I've heard several. Enumerating some of them: 1. I touched a file or files. Compile everything within a directory hierarchy that uses that file. Do not link. 2. I touched a file or files. Compile everything that uses that file. Do not link. 2a. I touched a C++ header file which is included all over the place. I anticipate that this change will break a specific set of .cpp files. Recompile *those files* right now. Do not recompile anything else. Do not link. It is *often* the case that the set of .cpp files in question is all the files in this directory, but in my experience even that is too many sometimes. For instance, if I'm adding a CSS feature and I have to touch nsCSSValue.h, I probably want to iterate on nsCSSParser.cpp and nsCSSValue.cpp until those are happy, and only then try rebuilding the rest of layout/style/. In the days of |make -f client.mk| I used to do this by copying compiler commands into a shell window, and then iterating on up-arrowreturn, but I don't know how to get full compiler commands out of mach. (Grumble.) |mach build LIST OF SPECIFIC .cpp FILES| would address this use case; one could use shell globs to get everything in directory X. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Disabling auto-play videos on mobile networks/devices?
On 2014-08-25 1:04 PM, Jonas Sicking wrote: That said, if you have ideas for how we can do even better, definitely speak up. I'd be happy to stop downloading animated gifs over a certain size over mobile connections if we can have some UI which lets the user resume the download. Seems to me there might be value in applying video controls-style controls to animated imgs *in general* -- not just for mobile. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Session Restore (sessionstore)
On 06/28/2014 08:12 AM, Tobias Besemer wrote: Forgetting closed pages - or the data to a page - would only be a problem is a scenario like this: The user editing a large text in a wiki, don't save it, close the page by mistake, close the browser without undo the close of the page, restart the browser and then try to undo the close of the page and have it old data back. This is *not* an unlikely scenario; it would happen naturally if the page closed by mistake is the only open tab, on Windows or Linux (where closing the only open tab exits the browser). zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RFC: maybe-uninitialized warning squelcher template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 'Way back in February I was musing about the possibility of a mfbt helper template that would allow us to silence variable X might be used uninitialized warnings without the negative effects of default-initializing those variables (mainly, that that could hide bugs if a variable *is* used uninitialized). I finally got around to implementing something, and it seems to work pretty well -- well enough for me to eliminate *all* of the maybe-uninitialized variable warnings in layout/. The patches are posted in this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1032994 The basic idea is that anytime you get a may be used uninitialized warning, you can just change that variable's definition to CondSetT var; which silences the compile-time warning and adds debug-only, fatal runtime assertions that the variable is initialized at every point of use. You are somewhat limited in what you can do with such a variable; the most important restriction is that you can't pass it to a function with an out-parameter of type T* or T. You must instead change that function to take CondSetT* or CondSetT. This is because many such functions in our code base don't always write their out-parameters; passing a reference to the CondSet object allows us to track that dynamically and get the assertion right. Other restrictions of note (unlike the above, these could potentially change if it were needed) are that there is no copy constructor, and that you can't store a NaN in CondSetfloat or CondSetdouble. A remaining major flaw, which I would welcome help correcting, is that it also squelches variable *is* used uninitialized warnings. (I'm not sure this is possible to avoid, without asking the compiler folks for a new __attribute__ or similar.) I consider this to be preliminary work, so I'm asking for feedback here rather than r?ing any of the patches. zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTsxuSAAoJEJH8wytnaapkPSgP/15z2cWBFenZjo+1FxXIiRWq tpteSKiFkmXB1aEYPSwkwH7pUJ44icHkixOSz6lYX4YdwCeYAWxCh5IlozCPLg81 4rGX0rql27oRd/RFnN9hNm/+zRtP/KKdjf94Tid6gDdW4k86Ce+AJ2QkkW/nL6JQ kWJ5NkESImyLLu50RawzZyj1o/eQFEXl4pixSrqLcQ1Ozs0/Z/BMb3QARgWFLQ/y AwTbe2IEfSogglhmZgh7RM8zwZmB/nkr2NRbsAwZ+qPrcEjmJntnzWq8ZrbBXJl6 OPlk8+lX6Vcrw3XgO/Olkr2Ie/tSuXgtL9PdVJVqnl2NJiq0UgX5Sms/PiqkohYQ ojE23ESghVIMd430PBtOLAWOhBI77zg/frzkW9dkW2sJnxocnahNkk77a9Ml9X/4 Hyj0O7verHu4N8IbgV0Ojg3M20tVx4LInM7flZwCqlGkHpT3ztctgdUfx9090Thx kx+0vMN5FAU7+GmNYzVuhweuVmrnfaympnbODlgNmrBLiWHrPdsHU8aoc1DH+ioG jFm7c+py6MsuI2Z7inxAMNq0jYaOHw9s4tckGWOTDMYSOzMXNh0XVKaROSnn+LID uBklD4yvYLafSbx/nCsQ5GapXysxmrZGGYW6LxcZ/NDYaZyLISGuV3JOxFygdgNH iVCi18PyVB0NJP1K5KAn =m+1i -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: connections to external hosts during tests now cause crashes
On 2014-06-17 11:01 AM, Nathan Froyd wrote: [bcc dev-tree-management] In the continuing effort to make our testsuites more reliable, bug 995417 has landed on inbound. This bug enforces the long-standing policy of no external network connections in the testsuite with code: external network connections will now crash the browser if and when they occur during tests, rather than intermittently causing failures. \o/ - If you need a host that doesn't exist (e.g. testing XMLHttpRequest error behavior), you ought to be able to just make one up. Make it sufficiently whimsical. The TLD `.invalid` is reserved for this purpose in RFC 2606 https://tools.ietf.org/html/rfc2606. If we used that consistently, it would be easy to tell, when reading unfamiliar tests, that a host is not supposed to exist. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/26/2014 09:03 PM, Boris Zbarsky wrote: On 4/26/14, 11:32 AM, Zack Weinberg wrote: it might be better to just create files in the ultimate target directory if we aren't already. We create the file before the user has picked the ultimate target directory. ... maybe we should stop doing that? Not in this bug though ;-) zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXQ7HAAoJEJH8wytnaapkfZYP/iOHjrT0X2WAFHTBrqW0FaJb eL5rtCZ02CXPGmM5P95ah73miomaPxldFMdgcsvYCr4LHRjvtgdGs6nCsNv8DfUm r/jrG+YVvM9Tc8gjoeZa85EJrcDc9vXsjjfJk3ZLt/kZHHFRrg49omyMsZlHyTlj M5NslCeQ1iZuK7d+Us8Dw8ql+c5uMYr8EwH5HeVV8iJcCzb7wpnDGXE9o/7MBTFi 3xwFV12nN+h0U2axDuJ5NRzfTI7oFOHhyx7KyUPvcNpULYBYGEV7PqTz2JCbO3to Th1MPMsGo1M4reGdf120SNrtgyrBVXvX54JflICAqrPg28K1HunXJvGh7BRudJR3 dWH+GY5UCu7hpavViK+AAEB7W9dhOVYp5akSf0Sub3n+Rq8F0N+u+3BLjikfDhVx 0CcpomyJBsp6D0HgKY7tPiLGgpH5068xVscgzeBwTqkWnDlihfjXxDaNbbtgrSXb 5f8mZiUXzx6JwWnrPYAfpr/cMlUATJfZyMzSj5wyXMrRULaCjtnxOL5oK6Asa19D 21ZCVpqh/kr3gW1ExROHSz61G65mjJ+V0NmD5Y0q5r25rmkiJhmxkGObVbchSdMA NDd5QbGMowAxv6WldLfImvJwrcjOX1n9wq7rz83uP9AjYkLNk2wM/LRb+hH4Unu+ ED3FxN4Fq1icUjpTKO5+ =DuO6 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2014 06:52 PM, Gavin Sharp wrote: It would help a lot with bug-clarity if both the record umask on startup and add API to OS.File changes were split into their own bugs. The debate is really about the OS.File API. Yeah, I should have done this months ago, but I was distracted by filesystem corruption. The record umask on startup changes are bug 1001842 and have been pushed to inbound. The OS.File API change is now bug 1001849. The API question depends a lot on the use cases people foresee. Are there any use cases identified for this API other than the download manager? OS.File is a fairly low-level API, so I tend to agree that it shouldn't be too tailored to the download manager case specifically, unless there's a lot of demand for that particular use case. A generic setPermisions API seems to fit with the rest of the OS.File API. honorUmask doesn't seem necessary at this point, unless there are identified use cases for it not mentioned. I think this is the wrong way to think about this. I claim that the operation do whatever is necessary on this platform to give this file the access permissions that it would have received if we had created it in its current location in the most natural way belongs in OS.File and not in its consumers, because it is security-critical, finicky to get right, and requires detailed understanding of platform conventions to get right. Moreover it should not be lumped into a generic setPermissions() call, which programmers will expect to do exactly as it is told rather than performing DWIMmery. I think this argument is compelling *whether or not* anyone besides the download manager ever needs this operation. (I happen to suspect that we already do need it elsewhere, but I can't commit to digging through the entire tree to find other cases. But any other context where we create files whose ultimate home is outside the profile directory is probably buggy right now in exactly the same way.) zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTW9KIAAoJEJH8wytnaapkwxUP/1ReeESl3nqASReHsOFVaTQq CFX6fuvvatRik+bOsP6Rtt6TrLxOk9Sukhg/cl//BKyHjqm8sM7oA+CEBC94w2dG u/OoepPu9BCN6geqyChEgOMvbUoHQ80t3htXTKSYyMWFpR/RCteuazb6b1dE69H7 7l5WlWoD9+bRdkBCnBgwLLk6O7tQT2S6zVMq/sq57wXrG8NGLxuqUZboUBaVVUGr GXmPZcMCAsLsjO3L9Mgq6pXm8tHeE2s6caojJwMVOvClUeHlpEVaczl3ILEtUkLR 7n+5DpjrBEaoK6bstHPkP3iEMm62ONL8rbdvI2eFbcwAv8oy7lqVtDYmWUPdvWQG wll44PFF9lFBsMkz/bFUBki39GHz7WnIfv8EJF1tFzITHs7Gvj4EubGu1C3hIitB XB7H2HMrLfWkXVy4XyosbZbynUh35EQrQT3hXyJHsQiURaLPdfzDCMqQ6GdQ3Aa4 IWrdBb0/7wIOqGwj8EuZCzOm9eAr143HjUJnm5zoUO0saXf5JyZQqtimQ2lk5NQP wddW/esbmCQCiwKClyYvj2gyG4kzJdYPZ/NCSkfCJLoIOHJ3c+bGBX8KUQfZR22i cjvNwLxP+uyUMDS+8aT6uvMgJetEujQg41BpO5vmgFalNN3ZkaMn5zSZgxRdD8O4 7nZbd5YV+3boWl01dpbk =I5l4 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: OS.File design issue from bug 961080 (making downloads respect umask)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/26/2014 12:17 PM, Dave Hylands wrote: The basic user/group/other permissions are always set to the mode argument to open() or mkdir(), and-not the umask. The permissions used by open are affected by umask. If you use open/creat to create a file with 0777 permisions and umask is 022 then you will get a 0755 file. See: http://linux.die.net/man/2/open and search for umask I am aware of this. I see now that the mode argument and-not the umask reads like the umask is irrelevant, but what I actually meant was the permissions are set to mode ~umask. (It now occurs to me that if the download manager moves files to a different directory after it finishes downloading them, we need to reset their ACL and group ownership as well as applying the umask. The umask would have already been applied when the file was created. Well, the entire point of bug 961080 is that files are being created mode (0600 ~umask) rather than (0666 ~umask) as is more typical, and that it's not safe to just switch to open(,, 0666), we have to chmod it later. If you copied the file, then it would get assigned the correct group. Being the owner of a directory but not a member of the group seems unusual. Consider a directory like this (numeric mode 3777): drwxrwsrwt 25 root root 4096 Apr 20 12:54 test.d Anyone can create files in this directory, and the group of files so created is forced to group 'root', *even if* they are not themselves members of that group. Similar, and rather more plausibly relevant to downloads, scenarios can be constructed with directory default ACLs. zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTXATaAAoJEJH8wytnaapkhqEP/2/IDDB0cmowE65tg1helk8W j3PC8j1iOPefT96n6HYZtj/o1jcakBbmO3QKSzE8BsHEV39N9R2qJwwupmiUdVFP 9Al9gSaYWmX0Cc9SPtIyrVdAn54WwudaF7CTkMIKpzywd793YfHE3nQW4PJNf6Hb c7gNLJytHA2+2hCamkqRfdyTV4mO1LaUrk8N1c/GcQNkkRJDiaw042LB3NOWFwJw dodMq/ByvjwJUi9ltJheGfwT+pMG8egK8g/zDes66n16XAwpXeqbiZlvwy1oDU0I pVHPfW6pFZtST2nT5Fj429WWCYyXC+kBN5yAhPwKQdWQeHJpok3c81Hg27Wy1Kkf YqHJ73Zkj4WWrMUQUVpmAxN+eq40OtNrh3+fEtMIuGewVCwuDxtGZWhcvsmTQUuH gA026kfY5euiILq2lda2Gw3dp8ZGkXhXuZWv3aoB4954TY/8SK6IUkt/7vhke6Tn ZKnFNxWIi+d3dWLesZgIOtAKczdPIhfdyURCeVEx+XHdZEIJllXIqRkp01cFNrUG rY/omKFU7PHM2qGP7HOseGO/aXsy3MqOb/YWTeq8MeEVcHRouge373RCfBRl9MtP o8cYh4eKgIHVfZjzVJzq1S/ckZy8LciiOtTFaHItz1Lh6Sj+KM3WStAv1IXEnpHQ 4pc5aNQZLSrXDFWR7h7J =s/jl -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Enable -Wswitch-enum? [was Re: MOZ_ASSUME_UNREACHABLE is being misused]
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
the enumeration type; otherwise the resulting
enumeration value is unspecified.
--- end quote
I take so :
typedef enum { a = 1, b, c = 10 } T;
T x;
Anyway, in my example above, a compiler can do anything
if x = 32 is executed (?).
Note here the enumeration value is unspecified, which I assume
merely means the compiler can choose anything for the value of x.
That might be considerably safer than undefined behavior of the
program.
Right. The intention here is that the compiler is allowed to pick some
underlying integer type, which must be able to represent all declared
values of the enumeration, and then silently accept in-range values and
truncate out-of-range values *for that type* -- but it's *not* allowed
to apply assume the programmer never does that optimizations as it
would for undefined behavior.
I don't know what the C++ committee's attitude was, but the C committee
specifically wanted to allow use of `enum` to declare bitmasks:
enum X {
X_FOO = 0x0001,
X_BAR = 0x0002,
/* ... exhaustive list of bit flags here ... */
X_BLURF = 0x8000
};
For that use case, any _combination_ of X_* flags must be representable
by the underlying integer type; note that many such combinations are
outside the *declared* range of values.
zw
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Enable -Wswitch-enum? [was Re: MOZ_ASSUME_UNREACHABLE is being misused]
-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, plus a default case, would now have to be expanded to cover all the enumerators. If there are few enough that this is sane. There are at least a few switches on nsresult in the tree, IIRC. Those would have to be rewritten as if/else. I think we have some other big enums lying around, although probably not so dramatic. Given the numbers posted elsewhere, I think this is clearly not going anywhere until someone has time and working development machine to find out just how burdensome it is. I have no idea how long it will be before I personally can do such experiments, alas. 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, such as if it was incorrectly cast. Our codebase has no shortage of dubious casts. Also, in many cases default:MOZ_CRASH() would kill control flow paths that make the compiler think variables might be used uninitialized. zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTPsnUAAoJEJH8wytnaapkyRgQALgWSAFa+FLLyYuFeuQis9zs KhqmNCYmCtTk9KNv8WhPTZCN6QYEekKPGKyoi5A+DXaRPqkqf6N2X3F8bWQbIrTB hZeRKm7Ks9TEvrBWQy8NwGV0Q2BftWpvvoKlHu44/Z8A1o8bW9X3kA/4GRltCi6+ jizXprEQ96opIOA2/7X7JdOG4jMnyNgeX236cgTQOIzf1RF2at70OGfVOZ+FcnPO UjctNx32L6xd306SIzWI/gwGXP7e9rxVl87/vjk+R8HcBoNNftkphRoZuP1L7h9E QNAAwdYUUa5TWrku9jeYIKgzI+gFTt2IjTsglIx3tHSlhB9Eigni6FzqYPjmUjQ+ sRn+726/cVDu8o9iKyZ3vTAxEYHHGFQVTLozlHp3zaVjqu02k6QvCZ4qkBJxU+0D zr3QZFg4WgN0FnS15b8HeeJKXfE1x8FQWsT7lVITlE7+kNq3DgHK7REpJvwxvGFX L6IdTY2Ag1V3ytywWgY8Qh1Tjvf73j+tMcO9Ka2auyGDJzwwem1BpfHJiCfQ4So4 SCJ/xH65p7Twgh7L//gIwMo2lhovP3/YTel5yVXSe5yIAzfoJ3mIMAKmF6vkcI55 ytD48TyNCxCCtEndc3QnsGA5EvRnM1tkAb01dfEVmrVmruFXoR6cTjJ3yiIgU3V3 OXTT6fwLxm/4bqUEwDcp =TW5u -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Enable -Wswitch-enum? [was Re: MOZ_ASSUME_UNREACHABLE is being misused]
-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 about enumeration values that are
not handled, but only if there is no default: clause. In basically
all of the instances I know about, default: MOZ_CRASH() would be
appropriate, but has been omitted in the name of continuing to get
that warning (many of these enumerations do regularly get new values
added).
I had been meaning for some time to file a feature request with the
gcc people for some way to get the warning even with the default case
present, but it turns out it's already there: -Wswitch-enum.
$ cat test.c
enum Foo { Bar, Baz, Quux };
extern void a(void);
extern void b(void);
extern void c(void);
void dispatch_1(enum Foo x)
{
switch (x) {
case Bar: a(); break;
case Baz: b(); break;
default: __builtin_trap();
}
}
void dispatch_2(enum Foo x)
{
switch (x) {
case Bar: a(); break;
case Baz: b(); break;
}
}
$ gcc -Wall -Wextra -fsyntax-only test.c
test.c: In function ‘dispatch_2’:
test.c:18:3: warning: enumeration value ‘Quux’ not handled in switch
[-Wswitch]
switch (x) {
^
$ gcc -Wall -Wextra -Wswitch-enum -fsyntax-only test.c
test.c: In function ‘dispatch_1’:
test.c:9:3: warning: enumeration value ‘Quux’ not handled in switch
[-Wswitch-enum]
switch (x) {
^
test.c: In function ‘dispatch_2’:
test.c:18:3: warning: enumeration value ‘Quux’ not handled in switch
[-Wswitch]
switch (x) {
^
Similarly for clang. Dunno about MSVC, but the cases of this that I
know about are all in OS-independent code so it wouldn't be a problem.
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 unpleasant that turns
out to be, but my development box has taken to corrupting its
filesystem if I merely do a 'hg update', so I'm kind of stuck, there.
Anyone interested in trying it?
zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTOuGbAAoJEJH8wytnaapke6YP/i1yyvKeWMbXX6b6eIa2Dv/v
njT6gRztp6V3LzreI8ShFNoUpt++Grvr1ZjO3cfpVOHujnq6GT4tJLG6KHI/E3MH
DdsAs6BdirmNwDhsWElQhZqtZ1f0ncu3/u2+tC2yOWEEkkTtJwjx7wBDQLZDrRdz
q5e0gE0wLh8pK1qf+LrU36o6N8T2+GLgqbEkNn/RnfGWINxG4PINm8EAZuFMnGt8
0Lpa9W03YVr1c53LpnH80jsfZ8JL4zszD7Sw1clTZgQEGeP31OXZaRZIFk+OAp3P
Yo13utlWb+AeSL8uQtQwW55YQAdJxx+fi7o+1szR/AgUfPs32dL6kmCIxcxx/eUb
0E1kmREhtmUKRA3DAM7SQ6DVXAS4TS+Rxa0HutLHHywU6GabNTeEMdyM8bseet+y
SlPqXf9o4UIwUuE9Sv+Jxvp9QnoIP6tFwyu99NVGDyPK6OoVRH4rjTeszxQckFs2
wjGmS0yGAsNgMcRHgav2CDvJVL+R+H0irgXQPaEl0CjonI9lGFYivp6tFZDgmDmI
u4sK9PEHhX/aECOqZgjexbS2QZGa7PcLjNfB251kl5/Oa+dTMNsvFH/pHm7s8rrZ
c/02VCzpl2b/qVkcwzggCZIFFu8J66YiniZlpnCBqrPpOcIGhpgMRJgbYSavgWSx
kwELrg4z3S+dsOs6x6zb
=b0ly
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Blink removing the concept of user styles?
On 03/02/2014 01:58 PM, Asa Dotzler wrote: How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. The checkin you refer to removed support for the equivalent of our userContent.css -- that is, a bare CSS file dropped into the profile directory, which is taken into account in the cascade. They were watching that file for changes mid-execution, which makes their support code more complicated than ours - we only read userContent.css on startup. It is not clear to me from that whether they removed (or intend to remove) support for *user styles* in general - that is, what the CSS Cascade draft calls Important user declarations and Normal user declarations. [1] The observation that extensions are a better way to do this sort of thing suggests not: such extensions would need a hook point into the core, which would be functionally equivalent to user styles. I would take the Stylish extension's 750,000 installs as a lower bound on the demand for *some* persistent mechanism whereby each user can adjust site styles to their liking, and to me that is enough to conclude that we should keep what we have. zw [1] http://dev.w3.org/csswg/css-cascade/#cascading ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Maybe-uninitialized warning helper template
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
This is a half-baked idea that occurred to me in the shower this
morning, but I think it's worth at least looking at. The trouble with
squelching maybe-uninitialized warnings via initialization, when
manual inspection indicates there's no problem, is that it's hard to
be sure there really *is* no problem, or that future code changes
won't introduce a problem. And the trouble with *not* squelching
those warnings is ... exactly the same (plus it contributes to
warnings fatigue). Catch-22.
But what if we did something like this:
namespace mfbt {
#if !defined MOZ_DEBUG !defined MOZ_VALGRIND
template typename T
using ConditionalUse = T;
#else
template typename T
class ConditionalUse
{
T val;
bool init;
public:
ConditionalUse() : T(), init(false)
{
MOZ_MAKE_MEM_UNDEFINED(val, sizeof(T));
}
T operator=(const T v)
{
val = v;
init = true;
return val;
}
T operator T()
{
MOZ_ASSERT(init);
return val;
}
// probably a bunch more operators
};
#endif
}
Then, when you get a false-positive maybe-uninitialized warning, you
could just replace T var; with mfbt::ConditionalUseT var; In a
release build, there would be no overhead; in a debug or valgrind
build you would get a prompt assertion on an invalid use. For
particularly dangerous-to-use-uninitialized types (e.g. pointers) the
release build could specialize the template to initialize the value to
a poison pattern.
Thoughts? I'm sure my sample code is all wrong, it's been a very long
time since I tried to write a generic wrapper template. ;-) And as
always with me, better names for things solicited.
zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTELjGAAoJEJH8wytnaapkRfIQALzeOGqarM35vfp4wCJh9jEZ
dQfE9jez4lutuEX3ELBaVUT+d+dZ/HslAbL0qLCb/cru/jvKUDnZJPgM42F9b1EI
repdD55vmZuOwIK3VQbx5RmjOYcgLPWSEgEYarW7/Kk59YDvr9Mdj3D8Ev5TFz6a
r4OnOrD6UVsbpjGMWgz4vfjIg5qjNGzC0t6PzJYi0Ha1qzYguNIiSdfSvviWz0sl
UtTpN/z+067GvzHeMH9fDH+l190yYqI8K7Pz8G+Q1rLNcTfygj0O/PmaSiPoSeaQ
alhbx3JoK1rtdONjnfweXi5IiBxCwPP6NeheHmCe2rDO6wSg0ORb6M220kJHmNZS
Nro80gj+ycHvAm/MtXAlfJhUAdO+dqf6a2O9wFQoLE5SrQvMBQlOO+a8sqvapMJB
I5NGQ9unT6qePScUvWMUvPqmSUDUenJ4u3vVeXDmu/qWzhP6vWAKgL1RiYdzjR/u
Nr5r3pBFHLlTiuDvE9LGhguBw1w3TDmdsiwWfnWmdkE+1yRGsFpQu9W4i0nSHaVR
enS+K+XmoB/nRii4TE02YvNyPcLL5/4J41dv4Adz7OHjojQSRPMslQ/bCnp4beXe
oKkJv7kvGhW9Ez+ZSkNapDySnir5Oer/DTkayqkF8i63Q7f1cPihh7UkyD9imS0v
ySu3LA7cqEdxwA423Htb
=Zidk
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Maybe-uninitialized warning helper template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 04:24 PM, Nicholas Nethercote wrote: On Sat, Mar 1, 2014 at 3:26 AM, Zack Weinberg za...@panix.com wrote: Then, when you get a false-positive maybe-uninitialized warning, you could just replace T var; with mfbt::ConditionalUseT var; In a release build, there would be no overhead; in a debug or valgrind build you would get a prompt assertion on an invalid use. For particularly dangerous-to-use-uninitialized types (e.g. pointers) the release build could specialize the template to initialize the value to a poison pattern. Interesting! But won't you still get warnings in opt builds? Yeah, I guess you would. We could maybe just live with that - at least, what *I* personally care about is not having to wade through a flood of preexisting maybe used uninitialized warnings to find any new warnings due to what I just changed, and I basically never do opt builds locally. There might also be compiler-specific ways to annotate the variable so it doesn't trigger warnings even in release builds; I'd be more comfortable doing that if it were coupled with automatic debug assertions. Or we could initialize it all the time; perhaps the people who don't like that idea would be more comfortable with it coupled with automatic debug assertions ;-) zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEQUCAAoJEJH8wytnaapkkZsP/RughC9LVDJkGWLc6dsjFL9z 6c8UULdHGJn/mtm61z5a572MX+x7g323zb6zPI64u2ybJyUnUVsB4gpU8yIXZoTD fOLawYS7GOXoAmowOfs74pbtFfKU3eHzBk3KkEtLKMq2RV4fdbqlav3hYS5Dlgyk 0rsx+fnVLTtGV8kK/fK8rKPEtIdpJDx+aLDc6LJ9kc2IiJbsvGTpPUUKScEnBy00 buZfCTOnBtXnDktsOhRiaQ5tRpdgyFhW8JhhcWIHtRpKrggD+U0yb4Z1CZuCsQmU DlZHbT5Udo2DGafBFmdUk9kyTysydo0EJ95ysV+cHTQkI6VkCghyEC5mKdRI4/ok lvpvVKitiT+sxC2aMU+GTvu4H+prV7xIiC/DYNvM5zQ1hDwB8Kn7h+UrJjl/hinP OJVSXwNR96JY/jg5ckdnw8vCIxyWjCmBhtWeYs+Pv4fBbIkYGUguffCEeuyWtGrY 2rBHZOmYwOMBM45LuJm9VtK79/Q0Ynv7h+sd8hhsO1IoVxhPfifQ/mHqZAZSRA3k Pnw05HrUN1A2qKlTnPWQ+ZnbQPyBeZYZ9XAHAf9zVIu8AN//02IookMXMwVj4Qkn 0A7+fTV72VlQqi0AbzrsUgmciMXs/wByokRkkrFVeXTe0ScC/qpX4zt/b2pz41U0 0LJ9bqK8OJsVPuDxNDWw =ywpM -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Maybe-uninitialized warning helper template
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/2014 05:19 PM, Ralph Giles wrote: On 2014-02-28 1:52 PM, Zack Weinberg wrote: Yeah, I guess you would. We could maybe just live with that - at least, what *I* personally care about is not having to wade through a flood of preexisting maybe used uninitialized warnings to find any new warnings due to what I just changed, and I basically never do opt builds locally. Is there a way to make the template generate 'T var = var;' in the release case when there's no initializer? That's be a useful hack to silence -Wunused-variable, -Wsometimes-uninitialized, etc. on gcc and clang. I'm not aware of any way to do that, but I am certainly not the cleverest C++ template guy in the room. zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTEQ5iAAoJEJH8wytnaapklZAP/irB6JvvgCxtVI0sraFLucuS 6y27d7fBikkiOeQM2KtfkCtDzYawXQ+FiC4TVuNdBk/LG/eI2MMXMuQIim+N8SUm 7dB1lOYX21OjU+K4N/HTh8m7AddM1xO75H06/+nJCFH8FxnSLy7csXonzt5ZyDHc 4DLKTgMZzgRq6po8CEopQFHdIqQoL1EGEr3ThBowDHTDyAwpH579ZazwJw1kLT+2 uEE4IRJPH8ntbV/ghqOdwzYVR3ih4yACo5nIS6jKzM6Ta8T5unmsUHrwD5+v4ebA 5MsiJSGn+pGl75vTigqwAnl5c/eSYXc1wrO2+mzjHgUuNI6Y1039tT9YtS0G0xQg k0EzFIWzpAgQ2PaVMbv22Dt7K3XZoxuteugwQO+fIrTWhQffLWyj4Fckx9hpbLu1 Lw8hdzygE3Y4F0ROcB8MepjiNIZnOMVkOO8Lo99rEkq874DqBGcwzaufpPnkbPMf 5WyfjQw5AAroTcjcQi/7t1rZ8KveIGg/gP/tlwbyImqqESfq3uvZM/+cmaXplRb3 A5HdPxIsRKTLZy7FiRqdtwJGh5RnUxwzoml2P7EyEZZ5K/uTDTx2LEB4ecbDh0Ju lvzpUoE6V7RXT8XCiHoj8OrIZFFGrMDpXxxpfHHxKhFEUQ77TmYQRGIXeWjGxfLB xLJGAwuJkAn9cVRuNg64 =R2YH -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Maybe-uninitialized warning helper template
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/28/2014 06:04 PM, Botond Ballo wrote:
Is there a way to make the template generate 'T var = var;' in
the release case when there's no initializer? That's be a
useful hack to silence -Wunused-variable,
-Wsometimes-uninitialized, etc. on gcc and clang.
I'm not aware of any way to do that, but I am certainly not the
cleverest C++ template guy in the room.
Can't you do
: val(val)
in the initializer list?
I was expecting that you couldn't, but the true answer is you can but
it doesn't suppress the warning:
template typename T
struct Hmm
{
T val;
Hmm() : val(val) {}
};
int main(int argc, char **argv)
{
Hmmint x;
if (argc 1)
return x.val;
}
=
test.cc:12:14: warning: ‘x.Hmmint::val’ may be used uninitialized in
this function
And in fact your original suggested hack doesn't seem to work anymore
either:
int main(int argc, char **argv)
{
int x = x;
if (argc 1)
return x;
}
=
test.cc:3:11: warning: ‘x’ is used uninitialized in this function
[-Wuninitialized]
int x = x;
^
Note how it's now warning on the *hack itself*.
On another note, I noodled around with the proposed wrapper class a
bit and I hit what may be an insurmountable problem: What do you do
if someone takes a pointer or reference to a wrapped variable? You
can't return a smart pointer, because it'll presumably be assigned to
a bare pointer; you don't want to unconditionally require a prior set,
because it might be about to be used as an out-parameter or some such
(I fully expect that happens *all the time* in our codebase). Maybe
something not entirely unlike getter_AddRefs? Would that be too annoying?
zw
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBCAAGBQJTER/cAAoJEJH8wytnaapkxIEQALTmy9iLCywRdUGERApoBQDw
JZdrVLH3c88o3S4C6yfiklMal1Ps8cZGYL95L2YMgqqfFad0FnVO5QdLgdn/wfvU
X+ro5L0lSWLYyCnb/aEPIAXJ8lDIVHUiy4b4A5KRrB0FYtf5k1wsBwY61DYij8Of
7TqKPQa/ny5GC1cjte0gnp6+3nh/U5hrPvixg865stIObfnj946lRbfP4yPSguJX
l5c4JJPyA8MdXo+hnvcNaM9dPIAtmolGuHDRqukbv2wLk4nuHFq9/64gpYl8LfT9
wXP0aEvFAHicHyWYMIa4yW4WuygKyfRPrsvAsWV6mZeDzJbgfnYqZdENkkcBRwQt
gBQER8p6IXNeTcbDAz9G4/c/i/doY+Qb3XCt+aU8hJWpW1Ia61BoXdZT8j91MV+M
xLoCJpzygVHaFZopy0qhz+otpmxQrsEqd2Byx9QtfKfoUIiliHAIEJG4QnBI9ZPb
CjEkfOd0hKZrTzB7jsVPUCtTvuZzz6p7cQL93utiYPMeoCsmKiLiPwrjlwzK64Ww
3t9cTYJZP6Xe2p9a1hJxXbx12se1r70zruGSxe1SV+a7FVqQWU9g4H6NVgW9JnZG
GwQSCtX3Qel8WVOqXVdivi9zI8/N4WrUrlONDmjmlK0+HRpKMlyHSqvDXGSuzkvV
xVLTvZcfIIQPnuxl0OgR
=72Ca
-END PGP SIGNATURE-
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Fixing build warnings [was: Re: Always brace your ifs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/23/2014 11:54 PM, Daniel Holbert wrote: On 02/22/2014 12:26 PM, Hubert Figuière wrote: FWIW, I (and others) have been working on that, as a side project, for a while now, and I think we're actually in pretty good shape right now. We currently have only 100-200 build warnings[1], if you filter out warnings from third-party libraries that we import (e.g. cairo, skia, protobuf, ICU, various media codecs). We also have ~260 directories (and growing) that are annotated as FAIL_ON_WARNINGS, meaning they're warning-free and they'll stay that way (enforced by TBPL). If you're noticing any particularly warning-spammy code, please file bugs (and label the directory as FAIL_ON_WARNINGs when they're fixed). That's what I do, and it's been working. Does that mean a patch to squelch the uninitialized variable warnings in layout will now be accepted? Those are the only warnings in layout on my (Linux, debug) builds. layout/base/FrameLayerBuilder.cpp:3462:56 [-Wmaybe-uninitialized] ?last? may be used uninitialized in this function layout/base/RestyleManager.cpp:2543:41 [-Wmaybe-uninitialized] ?lastContinuation? may be used uninitialized in this function layout/base/nsCSSRendering.cpp:297:40 [-Wmaybe-uninitialized] ?position? may be used uninitialized in this function layout/base/nsCSSRendering.cpp:632:34 [-Wmaybe-uninitialized] ?width? may be used uninitialized in this function layout/base/nsCSSRendering.cpp:2521:27 [-Wmaybe-uninitialized] ?isSolidBorder? may be used uninitialized in this function layout/base/nsCSSRendering.cpp:2525:35 [-Wmaybe-uninitialized] ?currentBackgroundClip? may be used uninitialized in this function layout/base/nsCSSRenderingBorders.cpp:662:105 [-Wmaybe-uninitialized] ?borderRenderColor? may be used uninitialized in this function layout/base/nsDisplayList.cpp:1745:28 [-Wmaybe-uninitialized] ?color? may be used uninitialized in this function layout/base/nsLayoutUtils.cpp:3370:11 [-Wmaybe-uninitialized] ?result? may be used uninitialized in this function layout/base/nsStyleSheetService.cpp:242:51 [-Wmaybe-uninitialized] ?message? may be used uninitialized in this function layout/generic/MathMLTextRunFactory.cpp:666:10 [-Wmaybe-uninitialized] ?mathVar? may be used uninitialized in this function layout/generic/nsBlockFrame.cpp:4866:72 [-Wmaybe-uninitialized] ?overflowLines? may be used uninitialized in this function layout/generic/nsFrame.cpp:6084:54 [-Wmaybe-uninitialized] ?blockFrameOrBR.nsContentAndOffset::mOffset? may be used uninitialized in this function layout/generic/nsFrame.cpp:6597:42 [-Wmaybe-uninitialized] ?thisBlock? may be used uninitialized in this function layout/generic/nsFrame.cpp:7025:38 [-Wmaybe-uninitialized] ?width? may be used uninitialized in this function layout/generic/nsHTMLReflowState.cpp:1980:37 [-Wmaybe-uninitialized] ?fType? may be used uninitialized in this function layout/generic/nsSelection.cpp:5713:34 [-Wmaybe-uninitialized] ?keycode? may be used uninitialized in this function layout/generic/nsSelection.cpp:5723:67 [-Wmaybe-uninitialized] ?amount? may be used uninitialized in this function layout/generic/nsTextRunTransformations.cpp:620:54 [-Wmaybe-uninitialized] ?child? may be used uninitialized in this function layout/style/nsCSSParser.cpp:2823:11 [-Wmaybe-uninitialized] ?rv? may be used uninitialized in this function layout/style/nsCSSParser.cpp:5969:43 [-Wmaybe-uninitialized] ?units? may be used uninitialized in this function layout/style/nsCSSParser.cpp:9658:14 [-Wmaybe-uninitialized] ?useCommas? may be used uninitialized in this function layout/style/nsCSSRuleProcessor.cpp:2619:52 [-Wmaybe-uninitialized] ?selectorForPseudo? may be used uninitialized in this function layout/style/nsCSSStyleSheet.cpp:286:21 [-Wmaybe-uninitialized] ?cmp? may be used uninitialized in this function layout/style/nsComputedDOMStyle.cpp:2542:26 [-Wmaybe-uninitialized] ?width? may be used uninitialized in this function layout/style/nsComputedDOMStyle.cpp:4269:29 [-Wmaybe-uninitialized] ?color? may be used uninitialized in this function layout/style/nsRuleNode.cpp:2864:55 [-Wmaybe-uninitialized] ?column? may be used uninitialized in this function layout/style/nsRuleNode.cpp:8627:63 [-Wmaybe-uninitialized] ?borderOffset? may be used uninitialized in this function layout/style/nsRuleNode.cpp:8631:65 [-Wmaybe-uninitialized] ?paddingOffset? may be used uninitialized in this function layout/style/nsRuleNode.cpp:8635:65 [-Wmaybe-uninitialized] ?textShadowOffset? may be used uninitialized in this function layout/style/nsStyleContext.cpp:585:22 [-Wmaybe-uninitialized] ?otherColor? may be used uninitialized in this function layout/tables/nsTableOuterFrame.cpp:1054:58 [-Wmaybe-uninitialized] ?captionFirstReflow? may be used uninitialized in this function layout/xul/nsSprocketLayout.cpp:967:25 [-Wmaybe-uninitialized] ?maxAscent?
Re: Fixing build warnings [was: Re: Always brace your ifs]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/27/2014 03:11 PM, Karl Tomlinson wrote: Daniel Holbert writes: On 02/27/2014 10:26 AM, Zack Weinberg wrote: Does that mean a patch to squelch the uninitialized variable warnings in layout will now be accepted? Those are the only warnings in layout on my (Linux, debug) builds. layout/base/FrameLayerBuilder.cpp:3462:56 [-Wmaybe-uninitialized] ?last? may be used uninitialized in this function If there's no perf impact, then probably, for at least some of them! The merits of maybe-uninitialized warning-fixes can vary on a case-by-case basis, because in some cases, it's just a false positive and the only way to fix it has a (small) perf cost. (which is why we don't treat it as an error in warnings-as-errors builds) More that just a perf cost. Explicitly initializing variables to garbage can hide real bugs from tools such as valgrind if they really are never set correctly later. Treating these as warnings, not errors, is probably the best thing here. If you see the warning and you've recently changed that code, then check it. If you haven't, you see the may be and ignore it. This is exactly the same thing dbaron said the last time I brought this up (quite some time ago - 2010, maybe?) I didn't buy it then and I don't buy it now. I think it is far more likely that a maybe-used-uninitialized true positive will *go unnoticed* because we've trained ourselves to ignore those warnings, and I don't think better precision in a valgrind run is worth the risk of letting a true positive slip through in a release build. Those bugs tend to be security critical. I also defy anyone to demonstrate a measurable performance impact from the tiny amount of additional machine code that might be emitted if we added initializations to squelch all those warnings. zw -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBCAAGBQJTD6OyAAoJEJH8wytnaapkaesQAI41/f22D3qEkEklw9WctsAp yJ2SpQ3fRu+HWenONIRNyKLWYZoYFX876Ef4oOJ9ebBVqx0DjwOS8NZjZRhZDZ89 DSLMpZUpgn4ZdEG+FWYAhV0deSdC6VeYnwrb2VB2exKr+rcoaLN9ksWDg8YkDyWo 2DO2rbL4QUj49OeECAQ8HP+iuEO9pqQsGowz5vK2wqr4cMiJVLXajM1QLWht+fVE JW5caOWmp9sJ9raG9C7OucFM7sgdAbe/Y3mi7WTKPMgv0Bq7FUFxxFM45aiV54c6 6l6oNJPN1Gmwv7YHW+J/jRqaTqJL2i6Uu3vorY4Vm2eF8V7DwkK/NVV8xnRumCEO NzFh67UCIVdSm6Ae5+UyRK0n5yPtRnSu13xbloe6glnBFqhYeQMrY1ouNqc6431Q 8662zVuFgL0swl7rJv9Wtz+5QpJesOPUrlPouRf8I4yxHwz/6OYW/wYg6QuDs4qa /R0mk7TSk0lKSCjSZzrWWo5M/6INSTbOtrfy7brsSy5LjnWKEVST0sBBvb4W3nqA TP0JNCm9KariKz8V8IUB5JI/LIl7J8//Sl5lsZ6q/ySn+tjzzIvWYnH3LE1i0TSk l3SYstBMf5msC0whXGCdZ8/JqCwWr+GNIjJSAKXkMNctRSileo4grvaftU5YZ7C3 O31oxvtOd7EfYvzstgDh =jHW4 -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: A proposal to reduce the number of styles in Mozilla code
On 2014-01-29 4:21 PM, Anthony Jones wrote: I don't think we should attempt style rewriting. One thing I wanted to explain is why I have focussed on clang-format-diff more than clang-format. My approach is to stop introducing ugliness so that we ratchet towards consistency. I suggest we do the same for style. The advantage of this approach is that it allows us to improve the tools as we go and avoids a flag day. On a number of style points - most importantly indentation depth - consistency within a single file is *far* more important than conformance with a global standard. If we're not prepared to reformat to the new style at least on a file-by-file basis, I don't think we should be trying to enforce global consistency wrt some of these things at all. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Support for non-UTF-8 platform charset
On 2014-01-17 4:39 AM, Henri Sivonen wrote: On Thu, Jan 16, 2014 at 7:28 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote: I found that TB generates during its execution UTF-8 file path name strings WITHOUT BOM and still contain supposedly a valid UTF8 path name. I'm pretty sure that file system paths on Linux are not supposed to contain a BOM. I'm certain they MUST NOT contain a BOM (in the RFC sense). Including a BOM would break code all over the place that assumes that filesystem paths can be concatenated with strcat(), that a path is absolute if and only if path[0] == '/', etc. All this use of iconv is sad, yes. I wouldn't be opposed to dropping the iconv code paths and using the OS X / Android code (that assumes that operating system's file system APIs always take UTF-8) for all *nix platforms. I'm going to do a little more research -- if I remember correctly, the Python crew tried to do this in their 3.0 release and ran into some trouble with it, and they came up with a more robust solution later in the 3.x series. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Mozilla style guide issues, from a JS point of view
Count me as another person in favor of an 80-column hard limit because of being able to open two files side-by-side with that limit, but not anything wider (even 100 is too wide). I spend a lot of time with an editor window tiled against a whole bunch of MXR tabs. I either don't care or can live with everything else under discussion. (If there were a chance of getting rid of the useless scoping prefixes on *everything*, as a big bang rewrite-the-entire-tree change, I would be for it. But somehow I don't think that's going to happen.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Please use NS_WARN_IF instead of NS_ENSURE_SUCCESS
On 2014-01-06 7:58 PM, Karl Tomlinson wrote: smaug sm...@welho.com writes: Why this deprecation? NS_ENSURE_ macros hid return paths. That was exactly why they were a Good Thing! Normal control flow was emphasized. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 641509
On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote: On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the comments I can't see any valid argument that backs up the decision to not fix the issue. At least none that would stand to the objection which I posted as a comment: Having a standard message always displayed is ok, but what's the reasoning behind not allowing to _add_ a custom text?!?!?!? [Note to list: I think this is an honest question which deserves a straight answer, and although I suspect the answer I'm about to give is somewhere in Bugzilla, I can't blame the poster for overlooking it in a giant bug thread full of shouting.] I am not the person who made this decision, but I agree with it, and this is why. If we allow the page to customize the onbeforeunload confirmation box _at all_, a malicious page can - just with clever wording - confuse the user into misunderstanding the standard message. The standard message we have right now is pretty hard to misunderstand, but we have actually seen things like IF YOU PRESS LEAVE PAGE YOUR COMPUTER WILL CRASHone! in the wild, and we have support tickets saying people were actually scared by that sort of thing. It's also conceivable that a malicious page could use Unicode trickery to render the standard message unreadable; we *might* be able to prevent that, but we would never be sure we had gotten every single way. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Support for non-UTF-8 platform charset
On 2013-11-26 5:40 AM, Neil wrote: Henri Sivonen wrote: On Windows, do we really need to pay homage to the pre-NT legacy when doing Save As? How about we just use UTF-8 for HTML Page, complete reserialization like on Mac? You'll need a BOM, of course. (MXR turns up so little that it makes me wonder non-UTF-8 support might have already gone away for practical purposes.) Gecko gets a little confused when you run Linux on a non-UTF8 file system, so I'd agree with this. FWIW some time later, I've seen both Linux and *BSD devs state that even if the user's locale uses a legacy encoding, all filesystem paths should still be treated as UTF-8. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: On closing old bugs
On 2013-11-27 2:36 AM, Gabriele Svelto wrote: While looking through bugzilla I often stumble in my searches on old bugs - sometimes very old - which after a quick look I realize have either already been fixed or won't be (because they pertain to some old, unsupported platform for example). Much of what I would have said here has been said by other people, so I just want to add that going through old bugs, one by one, and determining whether they are still relevant *is* tremendously valuable, and you should not feel discouraged from doing it. But it is important that you actually check each one. (When I've done this, more than half of the bugs *had* already been fixed or overtaken by events, and a fair number of the remaining ones did not have sufficient information to reproduce the problem, but about 25% were still live bugs.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Unified builds
On 2013-11-18 5:41 PM, Ehsan Akhgari wrote: I wouldn't go all the way to that extreme. The list of broken system headers is unfortunately quite large, and we already have lots of this pattern in the tree: #ifdef MyFunction // screw you, windows.h/X.h/etc. #undef MyFunction #endif A small note about this pattern: the #ifdef wrapper is unnecessary, i.e. it is safe to write only // screw you, X.h #undef MyFunction because #undef is specified to be a silent NOP when applied to an identifier with no macro definition. I am uneasy with the entire UNIFIED_SOURCES concept; I worry that it will lead to symbol-visibility problems down the road, when A.cpp defines things that aren't meant to be accessible elsewhere, B.cpp (which comes after it in the relevant unification block) starts using them, and nobody notices until decoupling them has become a major refactoring job. But I'm not so uneasy that I'm going to get in the way of faster builds. :-) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Poll: What do you need in MXR/DXR?
On 2013-10-25 11:10 AM, Ehsan Akhgari wrote: On 2013-10-25 10:45 AM, Erik Rose wrote: ... would it be better, from your point of view, to index the generated files or to magically turn up the IDL line attribute short foo when you search for function:GetFoo or function:SetFoo? (I'm not sure both are feasible; I just want to get an early read.) The latter is better in my opinion! If I can have only one, I agree the latter is better -- but I want to mention that sometimes I've needed to see what the I(P)DL compiler has produced from a particular definition file in order to fix a bug. For instance, a few years ago -- this may have been fixed since -- there were many gaps in the documentation of what C++ types corresponded to IDL types and vice versa, so one had to look at all three of the IDL, the generated .h, and the hand-written .cpp that expected to implement an interface to understand what was *really* going on. So, if you can make DXR do both, that would be better. (With a clear indication that certain files are generated, and where the real source is, if at all possible.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-11 1:08 PM, Ralph Giles wrote: On 2013-10-10 12:28 PM, Steve Fink wrote: It seems like the optimal efficiency vs surface exposure vs frequency of use tradeoff would be to do everything but the top formats (JPG, PNG, GIF?) in JS. That's what we do today. We support those three image formats with native code, and others can be supported by a js implementation, which anyone can write. *Can* anyone, though? Concretely, one would like to be able to write !doctype html script src=//cdn.provider.com/mysite/s/libtiff.js/script img src=//cdn.provider.com/mysite/2002/02/20/giant-map.tiff Those are cross-domain references for both the script and the image, just to be clear. Potential problems include: - Getting the content of the image file - Not triggering repeated downloads of the same image - Informing layout of the dimensions of the image - Acquiring a drawing context - Integrating properly with repaint, such that we get all the nice decode-on-draw, cache-and-discard-pixels optimizations - Ensuring that we don't introduce cross-domain data leaks in the process of enabling the above I am fairly sure that this is *not* possible right now in full generality; I think the best you can do from page script is issue an XHR for the image data (so it probably gets retrieved twice, and won't work cross-domain) and then manually replace the img with a canvas (and do your own caching and memory management). zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-10 12:56 PM, Brian Smith wrote: On Thu, Oct 10, 2013 at 3:43 AM, Till Schneidereit t...@tillschneidereit.net wrote: On Thu, Oct 10, 2013 at 12:00 PM, Gabriele Svelto gsve...@mozilla.com wrote: On 10/10/2013 02:36, Zack Weinberg wrote: In that vein, I think we should take a hard look at the image decoders. ... Considering the performance profile of some of our low-end platforms (most Firefox OS devices, low-end Android devices too) I don't think that would be a good idea right now. ... Note that we'll have SIMD support in JS in the not-too-distant future[1]. ... Things like this seem like really good ideas: http://blogs.msdn.com/b/ie/archive/2013/09/12/using-hardware-to-decode-and-load-jpg-images-up-to-45-faster-in-internet-explorer-11.aspx To whatever extent we can't match C or even hand-tuned assembly performance for image decoding with JS (using whatever combination of JIT, explicit SIMD coding, explicit GPU shader coding, etc. is necessary), I kinda think that points at a gap in the Web platform that we should fix - maybe not today, or tomorrow, but soon. We are, after all, pushing JS as the One True Virtual Machine for everything; anytime _we_ have to drop down to compiled language for something, that's a place where someone else might also find that JS did not meet their needs. This argument applies equally to XSLT, forms, editor, etc. as being discussed elsewhere, although I imagine the solutions would be different in each case :) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What platform features can we kill?
On 2013-10-09 12:01 PM, Gervase Markham wrote: In the spirit of learning from this, what's next on the chopping block? In between keep the C++ implementation and scrap entirely is reimplement in JS, and I think that should be seriously considered for things like XSLT where there's no question but what it increases our attack surface, but there is also a strong (if small) constituency. Where it is currently impossible to do something in JS, that points at a weakness in the platform - whether capabilities or just speed. In that vein, I think we should take a hard look at the image decoders. Not only is that a significant chunk of attack surface, it is a place where it's hard to innovate; image format after image format has died on the vine because it wasn't *enough* of an improvement to justify the additional glob of compiled code. Web-deliverable JS image decoders could open that up. The other thing that comes to mind is, if Web Components lives up to its promise, perhaps it could be used for the built-in form controls? That's also a big pile of hair, and form elements in odd places have been an ongoing source of crasher bugs. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: C++ Standards Committee meeting next week
On 2013-10-02 12:06 PM, Botond Ballo wrote: * Digit separators: int x = 1'000'000; // don't ask Gah. Breaks notion of a pp-number. Why on earth not 1_000_000, which doesn't? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implementing Pepper since Google is dropping NPAPI for good
On 2013-09-23 4:29 PM, Hubert Figuière wrote: PS: I truly believe that we should drop plugin support all together, but that's not what I'm discussing here. I think if we think our options going forward are implement PPAPI and dump plugins altogether, we should seriously consider both. Having said that, I think keep NPAPI around for compatibility's sake, but promulgate our own pure-JS object API is probably the most Mozillaish position. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Detection of unlabeled UTF-8
All the discussion of fallback character encodings has reminded me of an issue I've been meaning to bring up for some time: As a user of the en-US localization, nowadays the overwhelmingly most common situation where I see mojibake is when a site puts UTF-8 in its pages without declaring any encoding at all (neither via meta charset nor Content-Type). It is possible to distinguish UTF-8 from most legacy encodings heuristically with high reliability, and I'd like to suggest that we ought to do so, independent of locale. Having read through a bunch of the fallback encoding is wrong bugs Henri's been filing, I have the impression that Henri would prefer we *not* detect UTF-8, if only to limit the amount of 'magic' platform behavior; however, I have three counterarguments for this: 1. There exist sites that still regularly add new, UTF-8-encoded content, but whose *structure* was laid down in the late 1990s or early 2000s, declares no encoding, and is unlikely ever to be updated again. The example I have to hand is http://www.eyrie-productions.com/Forum/dcboard.cgi?az=read_countom=138forum=DCForumID24viewmode=threaded ; many other posts on this forum have the same problem. Take note of the vintage HTML. I suggested to the admins of this site that they add meta charset=utf-8 to the master page template, and was told that no one involved in current day-to-day operations has the necessary access privileges. I suspect that this kind of situation is rather more common than we would like to believe. 2. For some of the fallback-encoding-is-wrong bugs still open, a binary UTF-8/unibyte heuristic would save the localization from having to choose between displaying legacy minority-language content correctly and displaying legacy hegemonic-language content correctly. If I understand correctly, this is the case at least for Welsh: https://bugzilla.mozilla.org/show_bug.cgi?id=844087 . 3. Files loaded from local disk have no encoding metadata from the transport, and may have no in-band label either; in particular, UTF-8 plain text with no byte order mark, which is increasingly common, should not be misidentified as the legacy encoding. Having a binary UTF-8/unibyte heuristic might address some of the concerns mentioned in the File API should not use 'universal' character detection bug, https://bugzilla.mozilla.org/show_bug.cgi?id=848842 . If people are concerned about infecting the modern platform with heuristics, perhaps we could limit application of the heuristic to quirks mode, for HTML delivered over HTTP. I expect this would cover the majority of the sites described under point 1, and probably 2 as well. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Bug 851818 - Modernizing the Enter Bug Entry Page in Bugzilla
On 2013-03-18 12:39 PM, L. David Baron wrote: I'd actually like to see Core higher on the list for the no-canconfirm case. I think it's common for reasonably well-informed Web developers (who would have been able to choose a reasonably correct component within Core, given the list) to file standards bugs and end up with them languishing in Firefox::General. And I think appropriate guiding for Web developers filing bugs against the rendering engine is an important case. I agree with all of this, but I think that even very well-informed Web developers might find the Core component list daunting and incomprehensible. I think it'd be a good idea to have a special bug-entry wizard just for Firefox didn't render this page correctly that knows how to map standard web development terminology (HTML, JavaScript, CSS, tables, forms, accessibility, ...) to components, and which also encourages inclusion of things like self-contained minimal test cases, screen shots, and cross-browser comparisons. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 2013-03-03 10:25 PM, Boris Zbarsky wrote: On 3/3/13 10:12 PM, Zack Weinberg wrote: If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? The main difference is whether the web page will be able to see the events, I think. That's also what I thought, but it's good to have confirmation. In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? If it's a capturing handler, it should work, assuming nothing else higher up in chrome captures and eats them... So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window, and the immediate followup is whether it's possible for that handler to retrieve the window (originalTarget?) and learn its chrome structure (e.g. 'is this document in a tab, and if so, which tab?') zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firing events at the window vs. firing them at the chrome event handler
On 2013-03-04 9:53 AM, Boris Zbarsky wrote: On 3/4/13 9:10 AM, Zack Weinberg wrote: So I guess the next question is where does one put a capturing event handler so that it will see *all* events of the relevant type regardless of which window it was dispatched to or the contents of that window I don't think such a thing is possible in a world in which stopImmediatePropagation exists, is it? As in, if you have two handlers which both try to (1) see all events and (2) make sure nothing else sees them, then one of them will lose. It only needs to be certain of seeing the event despite anything content can do, and despite arbitrarily weird XUL structure. Also, I don't need to prevent anyone else from seeing the event, I just need to make sure that this handler does see it. (This is in aid of bug 650960, where I'm trying to replace direct C++ invocation of a dialog box with an indirection through an event, making it easier to replace the dialog box with a better UX later. For that, it might be more convenient in the long term if bubble-phase semantics applied within the chrome, so that a tab-level handler _could_ swallow an event and present tab-scoped UX, but if there was no tab, the global backstop would still apply. But that might be more complicated than I care to get into right now.) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Firing events at the window vs. firing them at the chrome event handler
If an event is dispatched from C++ using nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and 'cancelable' flags set false, what precisely is the difference between targeting it at a document's window and targeting it at the document's window's chrome event handler? In particular, if such an event is targeted at the window, is there any circumstance in which a handler registered from chrome JS on gBrowser will *not* get a crack at it? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Soliciting advice on #650960 (replacement for print progress bars)
https://bugzilla.mozilla.org/show_bug.cgi?id=650960 seeks to replace the existing print progress bars with something that isn't app-modal. Ignore musings in the description and first few comments about getting rid of them entirely and/or waiting for bug 629500. The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. However, the way this is implemented now is inconvenient (it's been shoehorned into the nsIWebProgressListener interface, which is not really fit for the purpose, and it involves some really icky [that's a technical term] back-and-forth between C++ and JS) and app-modal anything is Just Wrong. The existing patches in the bug have been vetoed because doorhanger notifications aren't even universally available within Firefox, never mind other applications. I am not aware of any universal alternative, and I know very little about XUL. I *think* that the low-level approach in the bug, of firing special chrome events at the window (plus some docshell goo to do the actual close suppression), is still viable, and I think doorhangers are appropriate for this when they're available. But I would like some help figuring out what a good universal-backstop *receiver* of those chrome events would look like, both in UX terms and implementation-wise. Thanks, zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Soliciting advice on #650960 (replacement for print progress bars)
On 02/25/2013 04:57 PM, Bobby Holley wrote: On Mon, Feb 25, 2013 at 1:28 PM, Benjamin Smedbergbenja...@smedbergs.uswrote: On 2/25/2013 4:14 PM, Zack Weinberg wrote: The current thinking is that we need *some* indication that a print job is in progress, because we need to prevent the user from closing the tab or window until the print job has been completely handed off to the OS. Why? Is the user allowed to interact with the tab contents (potentially modifying the DOM)? We clone static copies of documents for print preview. We could potentially do the same for normal printing, I'd think. The work I've already done on printing is at a rather lower level; I don't claim to understand fully how it works at the document/window/ shell level. But as far as I know, we do already clone a static copy of the document for normal printing. The only deep reason I can think of for keeping the tab around is that under some operating systems, closing the last tab triggers application shutdown, and it would probably violate expectations to delay that with no user-visible indication of why. However, I expect that if I tried to remove all the superficial reasons why we need to keep the tab around, I'd discover that it's a giant mess. Independent of all that, printing long documents can take tens of seconds just to complete the handoff to the OS print queue (I've been testing with the one-page HTML5 spec) and so I do think a user-visible indication of progress is desirable. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: print preview and documentation
On 2013-02-04 9:26 AM, Zack Weinberg wrote: On 2013-02-04 9:20 AM, rvj wrote: BTW Is there a pref that suppresses the annoying Preview Progress box .. or least are you able to move it out of the visible display area ? There isn't a pref, I misremembered. Does print.show_print_progress = false do what you want? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: printerenumeration (nsIPrinterEnumerator)
On 2013-01-30 2:23 PM, Daniel Holbert wrote: However, be warned that there are patches in bug 629500 to get rid of nsIPrinterEnumerator entirely (though that bug seems to have stalled a bit, so I don't know how soon that will happen). It's blocked on Windows-specific fixes (bug 693230) -- it looks like there's a patch in there, but nobody bothered to ask for review and it's also not clear whether it actually works. If anyone has low-level Windows GUI programming experience and spare brain cycles I could really use help with that part. The intention is still to remove nsIPrinterEnumerator entirely. All the tier-1 platforms nowadays discourage use of the OS-level printer enumeration APIs, because they have to talk to the network and may block the calling thread for an indefinite period. You're supposed to just let the OS-supplied print dialog boxes figure it out for you. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Alternative to math.h for pow() and other elementary functions?
Do we have any alternative to math.h when you need pow() or other such elementary functions? Normally I am Mr. We Should Use The Standard Library, but math.h in particular tends to have weird shit in it that causes conflicts with xpcom headers, surprising behavior when everything isn't a 'double', etc. I unfortunately don't remember the details, but nsCSSScanner.cpp has workarounds for these problems and I do remember that I tried to take them out once and the build blew up on Windows. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to math.h for pow() and other elementary functions?
On 2013-01-16 2:38 PM, Benoit Jacob wrote: For starters, the standard C++ cmath library is already much better. I was under the impression that the cwhatever headers could not be used in Mozilla code. Is that no longer the case? I also expect that cmath should contain at least as much weird shit as the corresponding math.h, since as far as I know no OS vendor has ever actually succeeded in making the cwhatever headers define only symbols in namespace std. Thus it would not help with my particular problem. However, the math headers are a bit of a special snowflake and I could *imagine* cmath not being as troublesome as math.h. Does anyone know for sure? zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of MOZ_MAKE_FLAGS Considered Unnecessary
On 2012-11-27 6:21 PM, Gregory Szorc wrote: On 11/27/12 2:55 PM, Chris Peterson wrote: On 11/27/12 2:35 PM, Gregory Szorc wrote: I feel the build system should be as fast as possible by default - no user action necessary. If you find that -j == # cores isn't providing the fastest builds possible, please present your data and we'll change the default value. A gnumake flag that obsessive mozconfig tweakers may want to test is --load-average (-l). You can specify a maximum load average to throttle the number of make -j jobs that are running simultaneously. You can specify a high -j to have many jobs available (e.g. 2 * # cores), but never run more than -l # cores. https://www.gnu.org/software/make/manual/make.html#Parallel If anyone has data showing -l to behave better than -j, I will happily incorporate it into the build system. That being said, I don't think using this flag is a good idea. I played with this a bit in the past. My experience was that the load average reacts much too slowly to new processes, so Make would fire off a huge batch of compilation processes (hundreds of them!), driving the computer deeply into swap. Tens of minutes later, that batch would all finish at the same time and Make would spawn a new batch. Overall results were disastrously bad. It might be possible to persuade the gmake developers to make -l look at the instantaneous CPU utilization rather than the one-minute load average (with some hysteresis) -- I can't imagine -l is useful to *anyone* with the behavior it currently has. It does what it does largely because that was the only gauge available back in the days of System V, I think. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-10 12:58 AM, Robert O'Callahan wrote: What exactly is the benefit here? As far as I know, using namespace A; using namespace B; where both A and B define Foo doesn't actually cause a compile error unless/until the code actually references Foo. The scenario I'm concerned with is when a .cpp file does 'using namespace A;' and then goes on to define a bunch of its *own* symbols; later someone adds a symbol to namespace A, and gets an unexpected break possibly miles from their own code. I see *avoiding* this phenomenon as the primary *benefit* of namespaces, and it's totally lost if you do 'using namespace' even in .cpp files. Sort of the same thing as adding DOM properties that then collide with website expandos. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-12 1:44 PM, Robert O'Callahan wrote: On Mon, Nov 12, 2012 at 9:37 AM, Zack Weinberg za...@panix.com wrote: The scenario I'm concerned with is when a .cpp file does 'using namespace A;' and then goes on to define a bunch of its *own* symbols; later someone adds a symbol to namespace A, and gets an unexpected break possibly miles from their own code. I see *avoiding* this phenomenon as the primary *benefit* of namespaces, and it's totally lost if you do 'using namespace' even in .cpp files. I see. Thanks for explaining that. I've never ever seen that happen, though. So I'm reluctant to pay an up-front cost to mitigate a problem whose size is unknown but could be smaller than any other problem we have. (And if it does occur in the future, the problem can still be quite easily fixed then.) OK, fair enough. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 1:28 PM, Kyle Huey wrote: I reviewed a patch today that had: using namespace mozilla; using namespace dom; The style guide should forbid `using namespace` altogether. Use only what you need. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed style guide modification: using declarations and nested namespaces
On 2012-11-09 10:49 PM, Robert O'Callahan wrote: On Fri, Nov 9, 2012 at 10:14 PM, Zack Weinberg za...@panix.com wrote: The style guide should forbid `using namespace` altogether. Use only what you need. I really don't think it should. I do not want to see source files full of difficult-to-maintain and unnecessary using boilerplate a la Java import. At least with Java imports, there are really good tools for managing the mess; we don't have those tools for C++. I challenge your presuppositions. The average file should need no more than one or two `using SYMBOL;` lines per header it includes. Maintaining this will not be significantly more difficult than maintaining the existing lists of header inclusions (which I admit is already too difficult). And I think that it is worth it in order not to lose one of the major benefits of namespaces, viz. that you don't have to worry about symbol conflicts with anything but what you actually use. zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)
On 2012-10-17 4:07 AM, Henri Sivonen wrote: On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com wrote: Until quite recently the FreeType autohinter did a very bad job on a surprising number of popular webfonts - rendering letters in the same word with inconsistent perceptual x-height, for instance. What kind of fonts? Bicameral or other? Display fonts or more normal fonts? I've mostly noticed it in bicameral Latin serif fonts. It's more obvious at display sizes but can show up at body-copy sizes as well. See http://savannah.nongnu.org/file/quattrocento-irregular-x-height.png?file_id=25578 for an example; according to Werner Lemberg, the autohinter could not handle fonts whose serif height exceeds an internal threshold. Unfortunately, that seems to include the bulk of the serif fonts on Google Web Fonts! http://savannah.nongnu.org/bugs/?36091 is the whole bug report. It _is_ fixed as of FreeType 2.4.11 -- but it looks like our bundled version is older than that (2.4.9 according to modules/freetype2/README.moz-patches) zw ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: Remove Linux PGO Testing
On 2012-10-11 3:12 PM, Anthony Jones wrote: On 11/10/12 19:33, Mike Hommey wrote: That being said, PGO on Linux is between 5 and 20% improvement on our various talos tests. That's with the version of gcc we currently use, which is 4.5. I'd expect 4.7 to do a better job even, especially if we added lto to the equation (and since we are now building on x86-64 machines, we wouldn't have to worry about memory usage ; link time could be a problem, though). Perhaps the problems can be resolved or ameliorated by bumping the minimum version of GCC that we support for PGO. Link-time optimization is described as an experimental new feature in the GCC 4.5.0 release notes[1]. The 4.6.0 release notes[2] say that it has now stabilized to the point of being usable, and the 4.7.0 release notes[3] describe it as still further improved both in reliability and code quality. If we're trying to use the 4.5 LTO, I'm not at all surprised to hear it's causing more trouble than it's worth. PGO is not the same thing as LTO, of course, but GCC's PGO was kind of an unloved stepchild until they got serious about LTO, so that, too, is likely to be much improved in 4.7. zw [1] http://gcc.gnu.org/gcc-4.5/changes.html [2] http://gcc.gnu.org/gcc-4.6/changes.html [3] http://gcc.gnu.org/gcc-4.7/changes.html ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
