Hi All,
From Martin Brejcha:
Index: src/lib/libssl/src/crypto/bio/bss_dgram.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/bss_dgram.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 bss_dgram.c
---
You might want to read up on floating point arithmetic. (rounding and
representation)
On 06/02/14 05:13, Daniel Dickman wrote:
I hit this problem while working with the numpy 1.8.1 regress suite
which has some tests that are currently failing.
Here is a reduced test case of the logaddexp2
Martin Pieuchot mpieuc...@nolizard.org writes:
On 28/05/14(Wed) 09:30, Jérémie Courrèges-Anglas wrote:
Martin Pieuchot mpieuc...@nolizard.org writes:
Diff below replace in_iawithaddr() + in_broadcast() - ifa_ifwithaddr(),
that does the same for IPv4 since broadcast addresses are added to
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating point arithmetic. (rounding and
representation)
Well, the difference between 4.994404 and 5.0 is a bit large to blame
rounding and binary representation. And other
Ok i might have been quick to judge, because i don't really trust
floating point arithmetic.
btw. exp2f works correct on i386.
On 06/02/14 10:17, Mark Kettenis wrote:
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating
Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating point arithmetic. (rounding and
representation)
Well, the difference
On Sun, Jun 01, 2014 at 09:17:09PM +0200, mijenix wrote:
Hope someone can commit the new product id.
Connecting to a WLAN network works and also hostap mode.
Thanks. I'll handle this.
Please fix your diff submission process. Your patch didn't
apply at all because all tabs were replaced with
Hi Benjamin,
On Mon, Jun 2, 2014 at 3:34 AM, Benjamin Baier program...@netzbasis.de wrote:
You might want to read up on floating point arithmetic. (rounding and
representation)
The error in floating point calculations is typically measured in
ulps. The error shown in this example is far too
On 28 May 2014 13:36, Martin Pieuchot mpieuc...@nolizard.org wrote:
On 28/05/14(Wed) 09:30, Jérémie Courrèges-Anglas wrote:
Martin Pieuchot mpieuc...@nolizard.org writes:
Diff below replace in_iawithaddr() + in_broadcast() - ifa_ifwithaddr(),
that does the same for IPv4 since broadcast
On Mon, Jun 2, 2014 at 5:33 AM, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating
From the numpy test suite, I think I might have found a bug in
nextafterl(3). The result_ld variable below comes back as nan on
i386. But doing the same calculations with floats returns the expected
values.
A test on Linux also shows the expected results for both the float and
long double cases.
abort? are you insane? no no no no...
On Sun, Jun 1, 2014 at 8:28 PM, Brent Cook bust...@gmail.com wrote:
Check for errors on write. Since SIGPIPE is ignored, play nicely with
pipelines by aborting on EPIPE.
---
src/apps/s_server.c | 7 +--
1 file changed, 5 insertions(+), 2
On Mon, Jun 02, 2014 at 11:41:52AM +0200, Stefan Sperling wrote:
On Sun, Jun 01, 2014 at 09:17:09PM +0200, mijenix wrote:
Hope someone can commit the new product id.
Connecting to a WLAN network works and also hostap mode.
Thanks. I'll handle this.
Please fix your diff submission
Date: Mon, 2 Jun 2014 07:34:59 -0400
From: Daniel Dickman didick...@gmail.com
From the numpy test suite, I think I might have found a bug in
nextafterl(3). The result_ld variable below comes back as nan on
i386. But doing the same calculations with floats returns the expected
values.
A
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 iteration on
all the addresses present in the RB-tree (or equivalent), let's use
ifa_ifwithaddr() instead.
One can actually read a file now! Yay!
I have another patch to allocate each message buffer from a pool as needed
rather than share one among all requests, but I'm not sure that it makes sense
to do so, as all requests go thru the same channel anyhow.
diff --git a/sbin/mount_9p/mount_9p.c
On Sun, 1 Jun 2014, Brent Cook wrote:
Since the random number generator no longer allows being seeded, remove
support for parsing the unused -rand option and the unused random buffer
variables. Better to fail than to be surprised when the RNG seed does not
function as expected.
This fixes
On Mon, Jun 02, 2014 at 09:51, Brent Cook wrote:
Is something like this more to taste? Or maybe just a simple (void)write()
as in libc/time/zic.c ?
I think maybe we want to save this one for later. If it's not
immediately obvious what the correct fix is, move along to something
where the
On Sat, May 31, 2014 at 17:32, Brent Cook wrote:
ASN1_STRING_data returns an unsigned char *, but strlcat's second
parameter is a const char *
---
src/crypto/ts/ts_rsp_verify.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/crypto/ts/ts_rsp_verify.c
On 6/2/14, Mark Kettenis mark.kette...@xs4all.nl wrote:
Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
From: Mark Kettenis mark.kette...@xs4all.nl
Date: Mon, 02 Jun 2014 09:34:20 +0200
From: Benjamin Baier program...@netzbasis.de
You might want to read up on floating point arithmetic.
On Thu, May 08, 2014 at 22:17, Fritjof Bornebusch wrote:
Hi tech,
there is no way you can go, after usage() was called, so dont't do it.
I can't apply this because the whitespace is mangled.
* Mike Belopuhov m...@belopuhov.com [2014-06-02 17:52]:
Any opinions on this? Does anyone make any sensible use of it?
Should we try to simplify this by removing ambiguous functionality?
I've been thinking that anchors as of now are a bit overengineered for
a long time.
When they were
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote:
What compiler warns about this? It's perfectly fine to pass a nonconst
string to a function that takes a const string.
char * vs unsigned char *?
Joerg
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote:
What compiler warns about this? It's perfectly fine to pass a nonconst
string to a function that takes a const string.
char * vs unsigned char *?
So this is a great way to lose focus.
The agenda is a step-by-step refactoring
On Mon, Jun 02, 2014 at 19:12, Joerg Sonnenberger wrote:
On Mon, Jun 02, 2014 at 12:33:14PM -0400, Ted Unangst wrote:
What compiler warns about this? It's perfectly fine to pass a nonconst
string to a function that takes a const string.
char * vs unsigned char *?
Oh, I guess. My feeling is
ok. Note this codepath is not compiled under OpenBSD.
Index: src/lib/libssl/src/crypto/bio/bss_dgram.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/bio/bss_dgram.c,v
retrieving revision 1.25
diff -u -p -u -p -r1.25 bss_dgram.c
Hi,
ld.so has a very basic malloc. This diff changes it to use a (somewhat
stripped) libc malloc with all the randomization and
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 integer bit, the following diff (an adaptation of the code in
glibc) should fix
I would like to remove our local patch that puts IO::Compress into an
architecture dependent directory. IO::Compress moves from
/usr/libdata/perl5/amd64-openbsd/5.18.2/IO/Compress to
/usr/local/perl5/5.18.2/IO/Compress.
This will require an additional change to sync the file sets.
OK?
The
29 matches
Mail list logo
