I created a bugzilla entry based on the information here.
Bug 1170578 - RFC: Buggy NSS dbm code ought to be updated
https://bugzilla.mozilla.org/show_bug.cgi?id=1170578
TIA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozil
Gordan has the right general idea to approaching this problem space.
On Mon, Jun 1, 2015 at 5:42 PM, Gordon Brander wrote:
> On June 1, 2015 at 17:34:48 , Jonas Sicking (jo...@sicking.cc) wrote:
>> I think we're already talking about reverse-engineering what search
>> engines and twitter/facebook
On 6/2/15 6:12 PM, Seth Fowler wrote:
If you write this:
auto val = Bar();
Foo(val);
I think to preserve the semantics of Foo(Bar()) you need:
auto& val = Bar();
Foo(val);
but apart from that nit, I totally agree.
-Boris
___
dev-platform mail
> On Jun 2, 2015, at 1:59 PM, L. David Baron wrote:
>
> Remember that if 'auto' is forbidden, people might get around it by
> not using a variable at all (and instead repeating the expression)
> rather than by writing the type explicitly on the variable... and
> this doesn't provide type informa
I am trying to use it and always return null.
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 6/2/2015 2:58 PM, smaug wrote:
Hi all,
there was some discussion in #developers about use of 'auto' earlier
today.
Some people seem to like it, and some, like I, don't.
The reasons why I try to avoid using it and usually ask to replace it
with the actual type when I'm
reviewing a patch
On Tue, Jun 2, 2015 at 1:59 PM, L. David Baron wrote:
>
> My assumption was that this would be for cases where neither the
> reader nor writer is likely to care about which integral type it is,
> and also cases that are near the threshold for whether to repeat (in
> source code or perhaps only in
On Tuesday 2015-06-02 13:43 -0700, Martin Thomson wrote:
> On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey wrote:
> >> auto len = aArray.Length();
> >> auto display = GetStyleDisplay()->mDisplay;
> >>
> >> It can save having to look up whether aArray.Length() returns size_t
> >> (I sure hope it does
Yeah, I like to ask myself whether I am losing any information by using
auto. If it ends up eliminating redundancy within a line of code, I like
to use it. OTOH if it eliminates useful human-friendly type information
from the code then I don't.
On 6/2/2015 2:43 PM, Martin Thomson wrote:
On Tu
On 06/02/2015 12:58 PM, smaug wrote:
> So, I'd like to understand why people think 'auto' is a good thing to use.
> (bz mentioned it having some use inside bindings' codegenerator, and
> sure, I can see that being rather
> valid case.)
One common "auto" usage I've seen is for storing the result of
On Tue, Jun 2, 2015 at 1:35 PM, Kyle Huey wrote:
>> auto len = aArray.Length();
>> auto display = GetStyleDisplay()->mDisplay;
>>
>> It can save having to look up whether aArray.Length() returns size_t
>> (I sure hope it does, though) or whether mDisplay is uint8_t or
>> uint16_t.
I have no s
On Tue, Jun 2, 2015 at 1:23 PM, L. David Baron wrote:
> On Tuesday 2015-06-02 22:58 +0300, smaug wrote:
> > So, I'd like to understand why people think 'auto' is a good thing to
> use.
> > (bz mentioned it having some use inside bindings' codegenerator, and
> sure, I can see that being rather
> >
On 02/06/15 21:58, smaug wrote:
> Perhaps my mind is too much on reviewer's side, and less on the code
> writer's.
I'd say it's the right place to put your mind. I always assume that code
I review (and hopefully code I write) will be read by countless
generations of contributors with much less exp
On Tuesday 2015-06-02 22:58 +0300, smaug wrote:
> So, I'd like to understand why people think 'auto' is a good thing to use.
> (bz mentioned it having some use inside bindings' codegenerator, and sure, I
> can see that being rather
> valid case.)
One context where I think it often makes sense is
Hi all,
there was some discussion in #developers about use of 'auto' earlier today.
Some people seem to like it, and some, like I, don't.
The reasons why I try to avoid using it and usually ask to replace it with the
actual type when I'm
reviewing a patch using it are:
- It makes the code hard
I'm announcing a new tool that can be used for performance analyzes at
runtime. It's called Backtrack and is built on top of Gecko Profiler
and Task Tracer.
The goal is to capture full code path flows from any point of the code
back to its source, crossing asynchronous callbacks, threads, pro
It's the mozcrt.lib for vs 2010.
Cause ms is automatcally relocate stricmp to _stricmp, but
mozcrt.lib doesn't do that.
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.moz
Thanks for all, that's really helped!.
2015-06-02 20:47 GMT+08:00 Honza Bambas :
> invoke DumpJSStack() from the debugger. It will output to console or to the
> VC++ output window.
>
> -hb-
>
>
> On 6/1/2015 11:26, 罗勇刚(Yonggang Luo) wrote:
>>
>>mozjs.dll!js::jit::BaselineScript::icEntryFromPC
invoke DumpJSStack() from the debugger. It will output to console or to
the VC++ output window.
-hb-
On 6/1/2015 11:26, 罗勇刚(Yonggang Luo) wrote:
mozjs.dll!js::jit::BaselineScript::icEntryFromPCOffset(unsigned int
pcOffset) Line 553 C++
mozjs.dll!js::jit::DebugModeOSRVolatileStub::invali
On Tuesday, 2 June 2015 02:17:09 UTC+5:30, Mike Hommey wrote:
> On Mon, Jun 01, 2015 at 12:51:23PM -0700, Meenakshi Shankar wrote:
> > On Thursday, 28 May 2015 08:09:55 UTC+5:30, Mike Hommey wrote:
> > > On Wed, May 27, 2015 at 11:38:30AM -0700, Meenakshi Shankar wrote:
> > > > Hi,
> > > >
> > >
20 matches
Mail list logo
