Nicholas Nethercote wrote:
More generally, "make it impossible to write code that performs badly"
isn't a worthy or feasible goal, IMO.
Easy-to-contrive hashtable collision DoS attack was an issue for Node.js
(server side) the other year. V8 took a mitigating patch:
https://github.com/v8/v8/
On Mon, Feb 10, 2014 at 8:24 AM, Kannan Vijayan wrote:
>
> The collision rate control is the bad behaviour I'm referring to. If a
> webapp is written so as to allow a user to generate atoms (not too hard
> since they get created in a bunch of places, esp. property-access related
> operations), the
On 2/7/2014, 4:55 PM, Nicholas Nethercote wrote:
And as I said before, choosing to not atomize based on length is a bad
idea: if 99% of the strings you deal with in a particular place are
atomized, but 1% are not, then you can't use pointer equality.
Forgot to reply to this earlier. I don't th
On 2/7/2014, 4:55 PM, Nicholas Nethercote wrote:
On Fri, Feb 7, 2014 at 1:40 PM, Kannan Vijayan wrote:
Not hashing the entire string sounds like a collision attack vector. Any
app or page coded in such a way as to enable an attacker to create interned
strings would open the browser to a DoS at
On Mon 10 Feb 2014 00:56, Nicholas Nethercote writes:
> For a long time I've had Cachegrind set up to run SunSpider in the
> shell. It's really useful being able to see instruction counts at the
> level of source code lines when optimizing.
>
> I just tried it today for the first time in a while,
5 matches
Mail list logo
