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 patc
>
> 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
Hi,
ld.so has a very basic malloc. This diff changes it to use a (somewhat
stripped) libc malloc with all the randomization and oth
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
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 feeli
> 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 refacto
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
* Mike Belopuhov [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 written, we had no clear
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.
On 6/2/14, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
>> From: Mark Kettenis
>>
>> > Date: Mon, 02 Jun 2014 09:34:20 +0200
>> > From: Benjamin Baier
>> >
>> > You might want to read up on floating point arithmetic. (rounding and
>> > representation)
>>
>> Well, the diffe
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 b/src/cry
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 corr
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 fix
Hi,
I've been chasing some bugs in the pfctl anchor code for a couple
of weeks and I'm not astonished at how loose the handling is in
general. Lot's of rules and checks are being violated by some
code paths while honoured by others. The problem I have is that
it's truly a rabbit's hole: almost e
> abort? are you insane? no no no no...
Me IRL: http://cdn.memegenerator.net/instances/400x/37703326.jpg
That’s the problem with swiss army knife programs; too many corner cases. I was
thinking about why SIGPIPE exists and something like this:
cat /dev/urandom | openssl s_server -quiet | cra
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 b/sbi
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.
> Date: Mon, 2 Jun 2014 07:34:59 -0400
> From: Daniel Dickman
>
> >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
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 submissio
abort? are you insane? no no no no...
On Sun, Jun 1, 2014 at 8:28 PM, Brent Cook 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 deletions(-)
>
> diff
>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
On Mon, Jun 2, 2014 at 5:33 AM, Mark Kettenis wrote:
>> Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
>> From: Mark Kettenis
>>
>> > Date: Mon, 02 Jun 2014 09:34:20 +0200
>> > From: Benjamin Baier
>> >
>> > You might want to read up on floating point arithmetic. (rounding and
>> > representation)
On 28 May 2014 13:36, Martin Pieuchot wrote:
> On 28/05/14(Wed) 09:30, Jérémie Courrèges-Anglas wrote:
>> Martin Pieuchot writes:
>>
>> > Diff below replace in_iawithaddr() + in_broadcast() -> ifa_ifwithaddr(),
>> > that does the same for IPv4 since broadcast addresses are added to the
>> > tree.
Hi Benjamin,
On Mon, Jun 2, 2014 at 3:34 AM, Benjamin Baier 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 big for the
existing
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 s
> Date: Mon, 2 Jun 2014 10:17:53 +0200 (CEST)
> From: Mark Kettenis
>
> > Date: Mon, 02 Jun 2014 09:34:20 +0200
> > From: Benjamin Baier
> >
> > 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
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
You might want to read up on floating point arithmetic. (rounding
> Date: Mon, 02 Jun 2014 09:34:20 +0200
> From: Benjamin Baier
>
> 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 OpenBSD platforms
(amd6
Martin Pieuchot writes:
> On 28/05/14(Wed) 09:30, Jérémie Courrèges-Anglas wrote:
>> Martin Pieuchot writes:
>>
>> > Diff below replace in_iawithaddr() + in_broadcast() -> ifa_ifwithaddr(),
>> > that does the same for IPv4 since broadcast addresses are added to the
>> > tree.
>>
>> This preven
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 pyth
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
--- src/lib/libssl/src/crypt
31 matches
Mail list logo
