>>
>> confirming that this patch fixes the failing numpy regress test on i386.
>>
>> let me know if you want me to test a different diff.
>
> Here's a better diff, inspired by what FreeBSD has.
>
> ok?
>
>
ok with me. numpy works with this diff too.
> Matthew, you obviously did not spot the evil 9p/util.h yet. This file
> ought to be named ozymandias.h.
>
> Also, I am vetoing the addition of -fms-extensions to the kernel build
> options. Whatever files require this option to build needs to be fixed
> to be proper, unambiguous, C99, instead.
Hello,
I just noticed r1.44 to t1_lib.c. I'm not sure that auditing
opaque_prf_input is a good use of anyone's time -- I think it might be
better to just run "unifdef -U TLSEXT_TYPE_opaque_prf_input" and be done
with it.
Here's the history of opaque_prf_input as I understand it:
- In 2006, the D
On Wed, 4 Jun 2014, Philip Guenther wrote:
> On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck wrote:
> > Matthew Dempsky wrote:
> > > Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces
> > around "->"
> >
> > Not in cited document, but noted.
>
> Read more of the existing kernel
On Wed, Jun 4, 2014 at 4:19 PM, M Farkas-Dyck wrote:
> Matthew Dempsky wrote:
> > Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces
> around "->"
>
> Not in cited document, but noted.
>
Read more of the existing kernel code.
> Oh, and no "static" functions in the kernel.
Matthew Dempsky wrote:
> Also, look at "man 9 style"; in particular, OpenBSD doesn't put spaces around
> "->"
Not in cited document, but noted.
> Oh, and no "static" functions in the kernel. They cause problems with ddb.
Even inline functions?
Miod Vallat wrote:
> Matthew, you obviously did
On 6/4/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 21:18:26 -0400
>> From: Daniel Dickman
>>
>> >
>> > Another bug. Intel chose an extended precision format with an
>> > explicit integer bit, and the code doesn't handle that. Assuming we
>> > don't support machines with extended precision
Matthew, you obviously did not spot the evil 9p/util.h yet. This file
ought to be named ozymandias.h.
Also, I am vetoing the addition of -fms-extensions to the kernel build
options. Whatever files require this option to build needs to be fixed
to be proper, unambiguous, C99, instead.
On Wed, Jun 4, 2014 at 2:00 PM, M Farkas-Dyck wrote:
> Would a rwlock do? The sender and recver operate asynchronously, so
> the sender needs to hold a lock while sending and release it when
> asleep, but it can't be a mutex as the send operation may sleep, so I
> used requ.ready as the lock, but
On 04/06/2014, Philip Guenther wrote:
> The only reason to care whether another kernel thread had made it far
> enough into tlseep as to be on a sleep queue is if it's calling wakeup()
> on that thread's wait channel, but you MUST use some sort of lock to
> protect that shared condition that the t
> It seems the correct thing to do here is to put the shared part in libc,
> list the file in KSRCS in lib/libc/Makefile.inc, and make copy-to-libkern.
> This allows for only one copy to need to be maintained, and avoids hard
> build-time dependency tentacles between lib/ and sys/.
> (If this is no
> Hi All,
>
> >From OpenSSL RT:
> http://rt.openssl.org/Ticket/Display.html?id=3278&user=guest&pass=guest
>
> len can be 0 as well, and in which case, memory isn't freed.
Correct. If successful, data is actually a malloc(len + 1), thus if
len == 0, we leak a \0 byte...
> Patch from Frantisek B
On Wed, Jun 04, 2014 at 18:17, Florian Zumbiehl wrote:
> Hi all,
>
> may I draw your attention to this (my) ticket in the OpenSSL bug tracker?
>
> http://rt.openssl.org/Ticket/Display.html?id=3226&user=guest&pass=guest
>
> The patch adds various error checks and fixes an undefined return value i
Hi all,
may I draw your attention to this (my) ticket in the OpenSSL bug tracker?
http://rt.openssl.org/Ticket/Display.html?id=3226&user=guest&pass=guest
The patch adds various error checks and fixes an undefined return value in
case of error that could happen despite the error checking that's i
config(char *) contains a hand-rolled version of getlist(char *). The only
difference
is that the hand-rolled version includes a NULL check before the strcmp.
Replace this
with a call to getlist(char *) instead, and move the NULL check there to
protect other
callers as well.
I think we can pr
RT5592 devices have a larger TXWI and RXWI than other adapters supported
by run(4). The following patch adds the offset adjustments that were
overlooked in r1.98.
Using the patch, I can connect to 11g and 11b APs, though there's still
one nit: after scanning channels in the 5GHz range, the adapter
The ftp.fr mirror is going down for an undefined period of time (could
be forever).
Please migrate to another mirror for the time being.
Hi.
So, ftp.fr should be back in about 10 days in full shape on a much much
better hardware for a long time hopefully ;-)
Sorry for the inconvenienc
On 3 June 2014 09:18, Martin Pieuchot wrote:
> On 02/06/14(Mon) 15:45, Martin Pieuchot wrote:
>> This diff is similar to the one that has been committed to handle the
>> SOCK_RAW binding. I'd like to stop using in_iawithaddr() *and*
>> in_broadcast(). Since these functions are just doing an iter
On 4 June 2014 12:30, Martin Pieuchot wrote:
> ok?
>
sure
On 04/06/14(Wed) 12:45, Bret Lambert wrote:
> On Wed, Jun 04, 2014 at 12:30:58PM +0200, Martin Pieuchot wrote:
> > ok?
>
> Seems reasonable enough; are there any alignment issues placing
> it on the stack?
Nop, it's just a structure used to do some address lookups, it's already
done like that in
On Wed, Jun 04, 2014 at 12:30:58PM +0200, Martin Pieuchot wrote:
> ok?
Seems reasonable enough; are there any alignment issues placing
it on the stack?
>
> Index: netinet/ip_input.c
> ===
> RCS file: /home/ncvs/src/sys/netinet/ip_in
ok?
Index: netinet/ip_input.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_input.c,v
retrieving revision 1.233
diff -u -p -r1.233 ip_input.c
--- netinet/ip_input.c 10 May 2014 12:30:27 - 1.233
+++ netinet/ip_input.c 4 Jun 20
> Date: Mon, 2 Jun 2014 21:18:26 -0400
> From: Daniel Dickman
>
> >
> > Another bug. Intel chose an extended precision format with an
> > explicit integer bit, and the code doesn't handle that. Assuming we
> > don't support machines with extended precision format that have an
> > implicit integ
Hi All,
>From OpenSSL RT:
http://rt.openssl.org/Ticket/Display.html?id=3278&user=guest&pass=guest
len can be 0 as well, and in which case, memory isn't freed.
Patch from Frantisek Boranek:
Index: lib/libssl/src/crypto/pkcs12/p12_kiss.c
=
On 2014 Jun 04 (Wed) at 02:19:49 -0500 (-0500), strake...@gmail.com wrote:
:On Tue, Jun 03, 2014 at 10:44:57PM -0700, Philip Guenther wrote:
:> > Yes, some code I copied verbatim from plan9port or earlier work of mine,
:> > so that's fully in plan9 or my habitual style.
:>
:> IF YOU COPIED MORE T
25 matches
Mail list logo
