When I ported Gecko to LLP64 model OS (Win64) several years ago, some
reviewers said, "Use PRUptrdiff for pointer size value instread of
PRUword." So I landed a fix by PRUptrdiff for this...
OK. I will file a bug for these situation. Some causes can replace with
uintptr_t.
On 2012/08/24 1
On 12-08-23 9:30 PM, Makoto Kato wrote:
How about PRUptrdiff? Most cases can changes to uintptr_t.
PRUptrdiff does not have a stdint equivalent. Really, the notion of an
unsigned difference type is meaningless. The few places in the code
which use PRUptrdiff need to be converted into somet
http://mxr.mozilla.org/mozilla-central/ident?i=PRUptrdiff
In NSPR, this is defiend as "typedef unsigned long PRUptrdiff;".
ptrdiff_t is C99 standard and allows negative, but uintptr_t is unsigned.
On 2012/08/24 10:44, Bas Schouten wrote:
Is ptrdiff_t not portable? As far as I know it's part o
On 8/23/2012 8:44 PM, Bas Schouten wrote:
Is ptrdiff_t not portable? As far as I know it's part of the standard.
ptrdiff_t is a signed type. PRUptrdiff is presumably unsigned.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.
On 2012年08月23日 18:11, Justin Lebar wrote:
I encourage you to consider using [infallible] in new code for
attributes whose getters never fail. Not only is it cleaner to call
such methods, but using [infallible] also draws attention to those
attributes which /may/ fail.
Before each time using [
Is ptrdiff_t not portable? As far as I know it's part of the standard.
- Original Message -
From: "Makoto Kato"
To: dev-platform@lists.mozilla.org
Sent: Friday, August 24, 2012 1:30:39 AM
Subject: Re: Gecko switched to use standard integer types
How about PRUptrdiff? Most cases can chan
How about PRUptrdiff? Most cases can changes to uintptr_t.
On 2012/08/23 1:35, Ehsan Akhgari wrote:
I just landed the patches in bug 579517 which switch all of the code in
mozilla-central and comm-central [1] to use the standard integer types
as opposed to NSPR integer types. Here's what this
Hello,
The Graphics meeting will take place this Monday at 2:30 PM US/Pacific
time. That could be Tuesday in your timezone.
Please first add your agenda items there:
https://wiki.mozilla.org/Platform/GFX/2012-August-27
* Every Monday at 2:30 PM Pacific Time
* +1 650 903 0800 x92 Conf# 99366
* +
On 12-08-22 8:29 PM, Philipp Kewisch wrote:
What is going to happen to PRTime? Is that going away too?
PRTime needs to be converted to mozilla::TimeStamp manually.
Cheers,
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lis
On Thu 23 Aug 2012 09:11:46 AM PDT, Hanno Schlichting wrote:
By default there's no import statement and no way to open files, or even just any of the
exception names. You can define functions, but not classes. One could add a special
import statement or some other function like "include" to all
On 23.08.2012, at 17:07 , Ehsan Akhgari wrote:
> I think Gregory's suggestion of using the python's ast module to limit the
> sorts of syntax constructs that we accept in the build manifest files is a
> great one. That would let us make python powerful enough for our needs, but
> not more powe
On 12-08-23 12:46 AM, Nicholas Nethercote wrote:
So...
Data-only formats such as JSON are too weak -- no comments, no conditionals.
Full languages (e.g. Python, Lua) are too powerful, which means it's
too tempting to use the full language features.
Should you invent something new? If it's jus
Background:
Message managers are used in JS code to communicate across potential
process layers. There are two kinds of message managers, (a) frame
message managers that correspond to windows and frames within those
windows, and (b) process message managers that correspond to specific
processes. B
On Thu, Aug 23, 2012 at 9:39 AM, David Rajchenbach-Teller
wrote:
> Generally, this design is rather good at separating tasks that need a
> full language (implemented as rules) from tasks that only need a trivial
> description (implemented as description files).
This discussion is focused solely o
While I do not advocate the use of ocamlbuild, we could draw some
inspiration from the design.
Essentially, an ocamlbuild-based build system is based around a library
of rules (implemented in OCaml, we could do the same in Python, of
course), and any number of trivial description files. OCamlBuild
On Thu, Aug 23, 2012 at 08:43:31AM -0400, Ben Hearsum wrote:
> Yeah, I think I agree. My experience in RelEng has biased me strongly
> towards not allowing even temporary hacks like that, because it's rare
> that we ever remove them, and end up with a pile of very difficult to
> maintain hacks (Tin
On 08/23/12 12:05 AM, Robert O'Callahan wrote:
> On Thu, Aug 23, 2012 at 8:40 AM, Ben Hearsum wrote:
>
>> On 08/22/12 04:38 PM, Gregory Szorc wrote:
>>> Let's think of what can be done to secure/limit Python. Disabling import
>>> has already been mentioned. That's a start.
>>
>> I think it's wort
I landed bug 780970 today, which adds [infallible], a new XPIDL attribute.
You can only use [infallible] within interfaces marked as
[builtinclass] (which means the interface may not be implemented in
JS), and [infallible] is only applicable at the moment on XPIDL
attributes which return primitive
18 matches
Mail list logo
