> I may have a terminology problem here. I expect that a random seed must
> change every time it is used, otherwise the pseudorandom number generator
> using it just returns the same value each time. Should we be talking about a
> salt rather than a seed?
You should read the several other threads,
> My concern is that you will end up with vastly more 'yield from's
> than places that require locks, so most of them are just noise.
> If you bite your nails over whether a lock is needed every time
> you see one, they will cause you a lot more anxiety than they
> alleviate.
Not necessarily. The
Benjamin Peterson writes:
> 2012/1/21 Stefan Krah :
> > Do you mean (void)write(...)? Many people think this is good practice,
> > since it indicates to the reader that the return value is deliberately
> > ignored.
>
> Not doing anything with it seems fairly deliberate to me.
It may be del
Paul McMillan wrote:
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb wrote:
I agree; it sounds really odd to throw an exception since nothing is actually
wrong and there's nothing the caller would do about it to recover anyway.
Rather than throwing an exception, maybe you just reseed the random
On Sat, Jan 21, 2012 at 4:19 PM, Jared Grubb wrote:
> I agree; it sounds really odd to throw an exception since nothing is actually
> wrong and there's nothing the caller would do about it to recover anyway.
> Rather than throwing an exception, maybe you just reseed the random value for
> the h
2012/1/21 gregory.p.smith :
...
> +/* Convert ASCII to a positive int, no libc call. no overflow. -1 on error.
> */
Is no libc call important?
> +static int _pos_int_from_ascii(char *name)
To be consistent with the rest of posixmodule.c, "static int" should
be on a different line from the signa
On 20 Jan 2012, at 10:49, Brett Cannon wrote:
> Why can't we have our cake and eat it too?
>
> Can we do hash randomization in 3.3 and use the hash count solution for
> bugfix releases? That way we get a basic fix into the bugfix releases that
> won't break people's code (hopefully) but we go wi
2012/1/21 Gregory P. Smith :
> On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah wrote:
>> Benjamin Peterson wrote:
>>> > Can't that give you another warning about the ssize_t being truncated to
>>> > int?
>>> > How about the following instead?
>>> >
>>> > (void) write(...);
>>>
>>> Also, if you use
On Sat, Jan 21, 2012 at 2:52 PM, Antoine Pitrou wrote:
> On Sat, 21 Jan 2012 23:39:41 +0100
> gregory.p.smith wrote:
>> http://hg.python.org/cpython/rev/61aa484a3e54
>> changeset: 74563:61aa484a3e54
>> branch: 3.2
>> parent: 74561:d01fecadf3ea
>> user: Gregory P. Smith
>> date
Glyph wrote:
Yes, but you /can/ look at a 'yield' and conclude that you /might/ need
a lock, and that you have to think about it.
My concern is that you will end up with vastly more 'yield from's
than places that require locks, so most of them are just noise.
If you bite your nails over whethe
On Sat, Jan 21, 2012 at 2:33 PM, Stefan Krah wrote:
> Benjamin Peterson wrote:
>> > Can't that give you another warning about the ssize_t being truncated to
>> > int?
>> > How about the following instead?
>> >
>> > (void) write(...);
>>
>> Also, if you use a recent enough version of gcc, ./conf
On Sat, 21 Jan 2012 23:39:41 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/61aa484a3e54
> changeset: 74563:61aa484a3e54
> branch: 3.2
> parent: 74561:d01fecadf3ea
> user:Gregory P. Smith
> date:Sat Jan 21 14:01:08 2012 -0800
> summary:
> Fixes issue
2012/1/21 Stefan Krah :
> Benjamin Peterson wrote:
>> > Can't that give you another warning about the ssize_t being truncated to
>> > int?
>> > How about the following instead?
>> >
>> > (void) write(...);
>>
>> Also, if you use a recent enough version of gcc, ./configure will
>> disable the war
Benjamin Peterson wrote:
> > Can't that give you another warning about the ssize_t being truncated to
> > int?
> > How about the following instead?
> >
> > (void) write(...);
>
> Also, if you use a recent enough version of gcc, ./configure will
> disable the warning. I would prefer if stop usin
2012/1/21 Antoine Pitrou :
> On Sat, 21 Jan 2012 21:51:43 +0100
> gregory.p.smith wrote:
>> http://hg.python.org/cpython/rev/d01fecadf3ea
>> changeset: 74561:d01fecadf3ea
>> branch: 3.2
>> parent: 74558:03e61104f7a2
>> user: Gregory P. Smith
>> date: Sat Jan 21 12:31:25
On Sat, 21 Jan 2012 21:51:43 +0100
gregory.p.smith wrote:
> http://hg.python.org/cpython/rev/d01fecadf3ea
> changeset: 74561:d01fecadf3ea
> branch: 3.2
> parent: 74558:03e61104f7a2
> user:Gregory P. Smith
> date:Sat Jan 21 12:31:25 2012 -0800
> summary:
> Avoid the c
On Fri, 2012-01-20 at 16:55 +0100, Frank Sievertsen wrote:
> Hello,
>
> I still see at least two ways to create a DOS attack even with the
> collison-counting-patch.
[snip description of two types of attack on the collision counting
approach]
> What to do now?
> I think it's not smart to reduce
Am Freitag, 20. Januar 2012 um 23:40 schrieb Vijay Majagaonkar:
> > > I am trying to build python 3 on mac and build failing with following
> > > error can somebody help me with this
> >
> > It is a known bug that Apple's latest gcc-llvm (that comes with Xcode 4.1
> > by default as gcc) miscompi
On Sat, Jan 21, 2012 at 7:50 AM, Matthew Woodcraft
wrote:
> Victor Stinner wrote:
>> I propose to solve the hash collision vulnerability by counting
>> collisions [...]
>
>> We now know all issues of the randomized hash solution, and I
>> think that there are more drawbacks than advantages. IMO
Victor Stinner wrote:
> I propose to solve the hash collision vulnerability by counting
> collisions [...]
> We now know all issues of the randomized hash solution, and I
> think that there are more drawbacks than advantages. IMO the
> randomized hash is overkill to fix the hash collision issue.
20 matches
Mail list logo
