LibreSSL memory leak fix
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/crypto/bio/bss_dgram.c 27 Apr 2014 20:26:48 - 1.25 +++ src/lib/libssl/src/crypto/bio/bss_dgram.c 2 Jun 2014 07:20:34 - @@ -1224,6 +1224,7 @@ dgram_sctp_ctrl(BIO *b, int cmd, long nu memcpy(authkey-sca_key[0], ptr, 64 * sizeof(uint8_t)); ret = setsockopt(b-num, IPPROTO_SCTP, SCTP_AUTH_KEY, authkey, sockopt_len); + free(authkey); if (ret 0) break;
Re: exp2(3) bug?
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 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?
---8---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
double x;
double y;
// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);
printf(expected: 5.0\n);
printf(actual: %f\n, y);
---8---
on a linux/x86_64 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 5.00
on an openbsd/i386 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 4.994404
Re: PRU_BIND in raw ip
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 the
tree.
This prevents listeners to bind on 255.255.255.255, something allowed
with the current code. Thoughts?
You're right, here's an updated diff that keeps this behavior.
Sorry, busy week-end. ok jca@
Index: netinet/raw_ip.c
===
RCS file: /home/ncvs/src/sys/netinet/raw_ip.c,v
retrieving revision 1.72
diff -u -p -r1.72 raw_ip.c
--- netinet/raw_ip.c 21 Apr 2014 12:22:26 - 1.72
+++ netinet/raw_ip.c 28 May 2014 11:35:15 -
@@ -465,9 +465,9 @@ rip_usrreq(struct socket *so, int req, s
break;
}
if (!((so-so_options SO_BINDANY) ||
- addr-sin_addr.s_addr == 0 ||
- in_iawithaddr(addr-sin_addr, inp-inp_rtableid) ||
- in_broadcast(addr-sin_addr, NULL, inp-inp_rtableid))) {
+ addr-sin_addr.s_addr == INADDR_ANY ||
+ addr-sin_addr.s_addr == INADDR_BROADCAST ||
+ ifa_ifwithaddr(sintosa(addr), inp-inp_rtableid))) {
error = EADDRNOTAVAIL;
break;
}
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: exp2(3) bug?
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 OpenBSD platforms
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
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 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?
---8---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
double x;
double y;
// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);
printf(expected: 5.0\n);
printf(actual: %f\n, y);
---8---
on a linux/x86_64 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 5.00
on an openbsd/i386 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 4.994404
Re: exp2(3) bug?
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 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
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
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 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?
---8---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
double x;
double y;
// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);
printf(expected: 5.0\n);
printf(actual: %f\n, y);
---8---
on a linux/x86_64 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 5.00
on an openbsd/i386 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 4.994404
Re: exp2(3) bug?
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 between 4.994404 and 5.0 is a bit large to blame
rounding and binary representation. And other OpenBSD platforms
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
And here is a fix. There actually isn't any i386-specific code, but
i386 is special and needs STRICT_ALIGN() to work properly for double
as well as float. FreeBSD made the same change a while ago:
http://svnweb.FreeBSD.org/base/head/lib/msun/src/math_private.h?revision=240827view=markup
Haven't run the regression tests yet with this change.
Index: src/math_private.h
===
RCS file: /cvs/src/lib/libm/src/math_private.h,v
retrieving revision 1.16
diff -u -p -r1.16 math_private.h
--- src/math_private.h 12 Nov 2013 20:35:09 - 1.16
+++ src/math_private.h 2 Jun 2014 09:30:13 -
@@ -349,7 +349,7 @@ do {
\
#defineSTRICT_ASSIGN(type, lval, rval) do {\
volatile type __lval; \
\
- if (sizeof(type) = sizeof(double)) \
+ if (sizeof(type) = sizeof(long double))\
(lval) = (rval);\
else { \
__lval = (rval);\
Re: [PATCH] Atheros AR9281 miniPCI-E new product id 2nd try
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 spaces.
Thank you very much.
Cheers,
Mathias
Index: if_athn_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_athn_pci.c
--- if_athn_pci.c 6 Dec 2013 21:03:03 - 1.14
+++ if_athn_pci.c 1 Jun 2014 19:09:11 -
@@ -94,6 +94,7 @@ static const struct pci_matchid athn_pci
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9160 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9280 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9281 },
+ { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9281_2 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9285 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR2427 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9227 },
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1728
diff -u -p -r1.1728 pcidevs
--- pcidevs 20 May 2014 15:02:24 - 1.1728
+++ pcidevs 1 Jun 2014 19:09:22 -
@@ -1840,6 +1840,7 @@ product ATHEROS AR5211_DEFAULT0x1112 AR
product ATHEROS AR5212_FPGA0xf013 AR5212
product ATHEROS AR5211_FPGA11B 0xf11b AR5211Ref
product ATHEROS AR5211_LEGACY 0xff12 AR5211Ref
+product ATHEROS AR9281_2 0xff1c AR9281
/* Atmel products */
product ATMEL AT76C506 0x0506 AT76C506
Re: exp2(3) bug?
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 big for the
existing calculation to be correct. I'm linking to the wikipedia
article for some background reading for you but there's a lot more
info on the web on this topic:
http://en.wikipedia.org/wiki/Unit_in_the_last_place
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 python function which
ends up calling exp2. Is this a bug in the openbsd exp2
implementation?
---8---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
double x;
double y;
// x = log2(5)
x = 2.32192809489;
// y = 2**(log2(5))
y = exp2(x);
printf(expected: 5.0\n);
printf(actual: %f\n, y);
---8---
on a linux/x86_64 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 5.00
on an openbsd/i386 machine:
# gcc -lm test.c ./a.out
expected: 5.0
actual: 4.994404
Re: PRU_BIND in raw ip
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 addresses are added to the tree. This prevents listeners to bind on 255.255.255.255, something allowed with the current code. Thoughts? You're right, here's an updated diff that keeps this behavior. OK
Re: exp2(3) bug?
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 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
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
And here is a fix. There actually isn't any i386-specific code, but
i386 is special and needs STRICT_ALIGN() to work properly for double
as well as float. FreeBSD made the same change a while ago:
Fixes my test case and the numpy test. So ok daniel@ for what it's worth...
http://svnweb.FreeBSD.org/base/head/lib/msun/src/math_private.h?revision=240827view=markup
Haven't run the regression tests yet with this change.
Index: src/math_private.h
===
RCS file: /cvs/src/lib/libm/src/math_private.h,v
retrieving revision 1.16
diff -u -p -r1.16 math_private.h
--- src/math_private.h 12 Nov 2013 20:35:09 - 1.16
+++ src/math_private.h 2 Jun 2014 09:30:13 -
@@ -349,7 +349,7 @@ do {
\
#defineSTRICT_ASSIGN(type, lval, rval) do {\
volatile type __lval; \
\
- if (sizeof(type) = sizeof(double)) \
+ if (sizeof(type) = sizeof(long double))\
(lval) = (rval);\
else { \
__lval = (rval);\
nextafterl(3) possible bug
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 linux/x86_64 ]---
# gcc -lm test2.c ./a.out
1.00e+00
-5.421011e-20
OK
1.00
-0.00
OK
---[ on openbsd/i386 ]---
# gcc -lm test2.c ./a.out
1.00e+00
nan -- this looks wrong
1.00
-0.00
OK
---[ test2.c ]---
#include stdio.h
#include stdlib.h
#include math.h
int main(void) {
long double one_ld;
long double zero_ld;
long double after_ld;
long double result_ld;
one_ld = 1.0L;
zero_ld = 0.0L;
after_ld = nextafterl(one_ld, zero_ld);
printf(%Le\n, after_ld);
result_ld = after_ld - one_ld;
// result_ld should not be nan
printf(%Le\n, result_ld);
if (result_ld 0)
printf(OK\n);
float one_f;
float zero_f;
float after_f;
float result_f;
one_f = 1.0;
zero_f = 0.0;
after_f = nextafterf(one_f, zero_f);
printf(%f\n, after_f);
result_f = after_f - one_f;
printf(%f\n, result_f);
if (result_f 0)
printf(OK\n);
}
Re: [PATCH 1/3] Check output of write() to stdout
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 deletions(-)
diff --git a/src/apps/s_server.c b/src/apps/s_server.c
index 77384ec..836d46b 100644
--- a/src/apps/s_server.c
+++ b/src/apps/s_server.c
@@ -1760,8 +1760,11 @@ sv_body(char *hostname, int s, unsigned char
*context)
i = SSL_read(con, (char *) buf, bufsize);
switch (SSL_get_error(con, i)) {
case SSL_ERROR_NONE:
- write(fileno(stdout), buf,
- (unsigned int) i);
+ if (write(fileno(stdout), buf, i)
== -1) {
+ if (errno == EPIPE) {
+ abort();
+ }
+ }
if (SSL_pending(con))
goto again;
break;
--
1.9.3
Re: [PATCH] Atheros AR9281 miniPCI-E new product id 2nd try
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 process. Your patch didn't
apply at all because all tabs were replaced with spaces.
Hmmm, I'm not so sure about this.
The ID 0xff1c seems to be used within Atheros during OFW emulation.
http://permalink.gmane.org/gmane.linux.drivers.ath9k.devel/4229
Can we safely assume that this ID always refers to a AR9281 device?
Perhaps only someone invovled with Atheros can tell.
This ID doesn't seem to be matched by drivers in other operating
systems. Can you confirm that?
Thank you very much.
Cheers,
Mathias
Index: if_athn_pci.c
===
RCS file: /cvs/src/sys/dev/pci/if_athn_pci.c,v
retrieving revision 1.14
diff -u -p -r1.14 if_athn_pci.c
--- if_athn_pci.c 6 Dec 2013 21:03:03 - 1.14
+++ if_athn_pci.c 1 Jun 2014 19:09:11 -
@@ -94,6 +94,7 @@ static const struct pci_matchid athn_pci
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9160 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9280 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9281 },
+ { PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9281_2 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9285 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR2427 },
{ PCI_VENDOR_ATHEROS, PCI_PRODUCT_ATHEROS_AR9227 },
Index: pcidevs
===
RCS file: /cvs/src/sys/dev/pci/pcidevs,v
retrieving revision 1.1728
diff -u -p -r1.1728 pcidevs
--- pcidevs 20 May 2014 15:02:24 - 1.1728
+++ pcidevs 1 Jun 2014 19:09:22 -
@@ -1840,6 +1840,7 @@ product ATHEROS AR5211_DEFAULT0x1112 AR
product ATHEROS AR5212_FPGA0xf013 AR5212
product ATHEROS AR5211_FPGA11B 0xf11b AR5211Ref
product ATHEROS AR5211_LEGACY 0xff12 AR5211Ref
+product ATHEROS AR9281_2 0xff1c AR9281
/* Atmel products */
product ATMEL AT76C506 0x0506 AT76C506
Re: nextafterl(3) possible bug
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 test on Linux also shows the expected results for both the float and
long double cases.
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 things. Not entirely happy with the fix though, so
I'm still thinking about improvements.
Index: src/ld80/s_nextafterl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
retrieving revision 1.4
diff -u -p -r1.4 s_nextafterl.c
--- src/ld80/s_nextafterl.c 12 Nov 2013 21:07:28 - 1.4
+++ src/ld80/s_nextafterl.c 2 Jun 2014 13:21:58 -
@@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
ix = esx0x7fff;/* |x| */
iy = esy0x7fff;/* |y| */
- if (((ix==0x7fff)((hx|lx)!=0)) || /* x is nan */
- ((iy==0x7fff)((hy|ly)!=0))) /* y is nan */
+ if (((ix==0x7fff)((hx=0x7fff|lx)!=0)) || /* x is nan */
+ ((iy==0x7fff)((hy-0x7fff|ly)!=0))) /* y is nan */
return x+y;
if(x==y) return y; /* x=y, return y */
if((ix|hx|lx)==0) { /* x == 0 */
@@ -47,31 +47,50 @@ nextafterl(long double x, long double y)
if(ixiy||((ix==iy) (hxhy||((hx==hy)(lxly) {
/* x y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if (hx = 0x8000) {
+ if (esx == 0) {
+ --hx;
+ } else {
+ esx -= 1;
+ hx = hx - 1;
+ if (esx 0)
+ hx |= 0x8000;
+ }
+ } else
+ hx -= 1;
}
lx -= 1;
} else {/* x y, x += ulp */
lx += 1;
if(lx==0) {
hx += 1;
- if (hx==0)
+ if (hx==0 || (esx == 0 hx == 0x8000)) {
esx += 1;
+ hx |= 0x8000;
+ }
}
}
} else {/* x 0 */
if(esy=0||(ixiy||((ix==iy)(hxhy||((hx==hy)(lxly)){
/* x y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if (hx = 0x8000) {
+ esx -= 1;
+ hx = hx - 1;
+ if ((esx0x7fff) 0)
+ hx |= 0x8000;
+ } else
+ hx -= 1;
}
lx -= 1;
} else {/* x y, x += ulp */
lx += 1;
if(lx==0) {
hx += 1;
- if (hx==0) esx += 1;
+ if (hx==0 || (esx == 0x8000 hx == 0x8000)) {
+ esx += 1;
+ hx |= 0x8000;
+ }
}
}
}
in_pcbbind() and in_broadcast/in_iawithaddr
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.
This diff should not introduce any behavior change concerning SOCK_DGRAM
and binding to multicast addresses.
Ok?
Index: netinet/in_pcb.c
===
RCS file: /home/ncvs/src/sys/netinet/in_pcb.c,v
retrieving revision 1.155
diff -u -p -r1.155 in_pcb.c
--- netinet/in_pcb.c7 May 2014 08:26:38 - 1.155
+++ netinet/in_pcb.c2 Jun 2014 13:37:59 -
@@ -261,14 +261,19 @@ in_pcbbind(struct inpcb *inp, struct mbu
reuseport = SO_REUSEADDR|SO_REUSEPORT;
} else if (sin-sin_addr.s_addr != INADDR_ANY) {
sin-sin_port = 0; /* yech... */
- if (!(so-so_options SO_BINDANY)
- in_iawithaddr(sin-sin_addr,
- inp-inp_rtableid) == NULL)
+ if (!((so-so_options SO_BINDANY) ||
+ (sin-sin_addr.s_addr == INADDR_BROADCAST
+so-so_type == SOCK_DGRAM))) {
+ struct in_ifaddr *ia;
+
+ ia = ifatoia(ifa_ifwithaddr(sintosa(sin),
+ inp-inp_rtableid));
/* SOCK_RAW does not use in_pcbbind() */
- if (!(so-so_type == SOCK_DGRAM
- in_broadcast(sin-sin_addr, NULL,
- inp-inp_rtableid)))
- return (EADDRNOTAVAIL);
+ if (ia == NULL || (sin-sin_addr.s_addr ==
+ ia-ia_broadaddr.sin_addr.s_addr
+ so-so_type != SOCK_DGRAM))
+return (EADDRNOTAVAIL);
+ }
}
if (lport) {
struct inpcb *t;
Re: 9p
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/sbin/mount_9p/mount_9p.c
new file mode 100644
index 000..418f1f7
--- /dev/null
+++ b/sbin/mount_9p/mount_9p.c
@@ -0,0 +1,18 @@
+#include sys/param.h
+#include sys/mount.h
+#include stdio.h
+#include err.h
+
+int
+main (int argc, char *argu[])
+{
+ struct p9p_args args;
+ int c;
+
+ if (argc 3) errx (1, usage: %s fd path, argu[0]);
+ args.fd = strtol (argu[1], 0, 10);
+ args.msize = 1 20;
+ c = mount (MOUNT_P9P, argu[2], 0, args);
+ if (c) err (1, failed to mount);
+ return 0;
+}
diff --git a/sys/9p/9p.c b/sys/9p/9p.c
new file mode 100644
index 000..37c5ebd
--- /dev/null
+++ b/sys/9p/9p.c
@@ -0,0 +1,251 @@
+#include sys/param.h
+#include sys/malloc.h
+#include sys/systm.h
+#include sys/file.h
+#include 9p.h
+#include util.h
+
+int read9pmsg (struct file *fp, uint8_t *msg, size_t n) {
+ ssize_t size;
+ int c;
+
+ if (n 7) return EMSGSIZE;
+ c = read (fp, msg, 7);
+ if (c) return c;
+ LOAD32LE(size, msg);
+ if (size 7) return EIO;
+ switch (msg[4] /* type */) {
+ // Special case for TWrite and RRead, lest we copy huge data
+ case RRead:
+ size = 11;
+ break;
+ case TWrite:
+ size = 23;
+ break;
+ }
+ if (n size) return EMSGSIZE;
+ return read (fp, msg + 7, size - 7);
+}
+
+int write9pmsg (struct file *fp, uint8_t *msg) {
+ size_t size;
+
+ LOAD32LE(size, msg);
+ switch (msg[4] /* type */) {
+ case RRead:
+ size = 11;
+ break;
+ case TWrite:
+ size = 23;
+ break;
+ }
+ return write (fp, msg, size);
+}
+
+size_t loadQid (Qid *p_qid, uint8_t *msg) {
+ p_qid - type = msg[0];
+ LOAD32LE(p_qid - vers, msg + 1);
+ LOAD64LE(p_qid - path, msg + 5);
+ return 13;
+}
+
+size_t storQid (Qid *p_qid, uint8_t *msg) {
+ msg[0] = p_qid - type;
+ STOR32LE(p_qid - vers, msg + 1);
+ STOR64LE(p_qid - path, msg + 5);
+ return 13;
+}
+
+static size_t vsscan9p1 (uint8_t *msg, char fmt, void *p) {
+ size_t l;
+ switch (fmt) {
+ case '0':
+ *(uint8_t *)p = msg[0];
+ return 1;
+ case '1':
+ LOAD16LE(*(uint16_t *)p, msg);
+ return 2;
+ case '2':
+ LOAD32LE(*(uint32_t *)p, msg);
+ return 4;
+ case '3':
+ LOAD64LE(*(uint64_t *)p, msg);
+ return 8;
+ case 'd':
+ return loadDir (p, msg);
+ case 'q':
+ return loadQid (p, msg);
+ case 's':
+ LOAD16LE(l, msg);
+ *(char **)p = malloc (l + 1, M_TEMP, M_WAITOK);
+ strlcpy (*(char **)p, msg + 2, l + 1);
+ return (2 + l);
+ default:
+ panic (bad 9p message format spec);
+ }
+}
+
+static size_t vsprint9p1 (uint8_t *msg, char fmt, void *p) {
+ size_t l;
+ char *xs;
+ switch (fmt) {
+ case '0':
+ if (msg) msg[0] = *(uint8_t *)p;
+ return 1;
+ case '1':
+ if (msg) STOR16LE(*(uint16_t *)p, msg);
+ return 2;
+ case '2':
+ if (msg) STOR32LE(*(uint32_t *)p, msg);
+ return 4;
+ case '3':
+ if (msg) STOR64LE(*(uint64_t *)p, msg);
+ return 8;
+ case 'd':
+ return storDir (p, msg);
+ case 'q':
+ return (msg ? storQid (p, msg) : 13);
+ case 's':
+ xs = *(char **)p;
+ l = xs ? strlen (xs) : 0;
+ if (msg) {
+ STOR16LE(l, msg);
+ if (xs) memcpy (msg + 2, xs, l);
+ }
+ return (2 + l);
+ default:
+ panic (bad 9p message format spec);
+ }
+}
+
+#define ATOFFSET(t, p, r) (*(t *)((uint8_t *)(p) + r))
+
+static size_t vsscan9p (uint8_t *msg, char *fmt, void *p, size_t rs[]) {
+ size_t n;
+ uint8_t *q, *msg0;
+ msg0 = msg;
+ for (; fmt[0]; fmt++, rs++) switch (fmt[0]) {
+ case 'l':
+ msg += 2;
+ rs--;
+ break;
+ case 'n':
+ LOAD16LE(n, msg);
+ msg += 2;
+ ATOFFSET(uint16_t, p, rs[0]) = n;
+ fmt++;
+ rs++;
+ q = malloc (sizeof (void *)*n, M_TEMP, M_WAITOK);
+ ATOFFSET(void *, p, rs[0]) = q;
+ for (size_t ii = 0; ii n; ii++) {
+ size_t m = vsscan9p1 (msg, fmt[0], q);
+
Re: [PATCH 6/7] remove parsing of -rand options in openssl apps
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 compiler warnings about unused random seed variables.
Commited, thanks.
---
src/apps/cms.c | 9 -
src/apps/dgst.c | 8 ++--
src/apps/dhparam.c | 10 +-
src/apps/dsaparam.c | 7 +--
src/apps/ecparam.c | 9 +
src/apps/gendh.c| 10 +-
src/apps/gendsa.c | 11 ++-
src/apps/genrsa.c | 9 -
src/apps/pkcs12.c | 10 --
src/apps/rand.c | 10 +-
src/apps/req.c | 9 -
src/apps/s_client.c | 8 +---
src/apps/s_server.c | 7 ---
src/apps/smime.c| 10 --
src/apps/ts.c | 7 +--
15 files changed, 11 insertions(+), 123 deletions(-)
diff --git a/src/apps/cms.c b/src/apps/cms.c
index 56a7c95..76178b4 100644
--- a/src/apps/cms.c
+++ b/src/apps/cms.c
@@ -127,7 +127,6 @@ cms_main(int argc, char **argv)
char *to = NULL, *from = NULL, *subject = NULL;
char *CAfile = NULL, *CApath = NULL;
char *passargin = NULL, *passin = NULL;
- char *inrand = NULL;
const EVP_MD *sign_md = NULL;
int informat = FORMAT_SMIME, outformat = FORMAT_SMIME;
int rctformat = FORMAT_SMIME, keyform = FORMAT_PEM;
@@ -315,11 +314,6 @@ cms_main(int argc, char **argv)
BIO_printf(bio_err, Invalid OID %s\n, *args);
goto argerr;
}
- } else if (!strcmp(*args, -rand)) {
- if (!args[1])
- goto argerr;
- args++;
- inrand = *args;
}
#ifndef OPENSSL_NO_ENGINE
else if (!strcmp(*args, -engine)) {
@@ -553,9 +547,6 @@ argerr:
BIO_printf(bio_err, -engine e use engine e, possibly a
hardware
device.\n); #endif
BIO_printf(bio_err, -passin arginput file pass phrase
source\n);
- BIO_printf(bio_err, -rand file:file:...\n);
- BIO_printf(bio_err,load the file (or the files
in the
directory) into\n); -BIO_printf(bio_err,the
random
number generator\n); BIO_printf(bio_err, cert.pem recipient
certificate(s) for encryption\n); goto end;
}
diff --git a/src/apps/dgst.c b/src/apps/dgst.c
index 23b7d40..a862da9 100644
--- a/src/apps/dgst.c
+++ b/src/apps/dgst.c
@@ -116,7 +116,7 @@ dgst_main(int argc, char **argv)
int debug = 0;
int keyform = FORMAT_PEM;
const char *outfile = NULL, *keyfile = NULL;
- const char *sigfile = NULL, *randfile = NULL;
+ const char *sigfile = NULL;
int out_bin = -1, want_pub = 0, do_verify = 0;
EVP_PKEY *sigkey = NULL;
unsigned char *sigbuf = NULL;
@@ -151,11 +151,7 @@ dgst_main(int argc, char **argv)
separator = 1;
else if (strcmp(*argv, -r) == 0)
separator = 2;
- else if (strcmp(*argv, -rand) == 0) {
- if (--argc 1)
- break;
- randfile = *(++argv);
- } else if (strcmp(*argv, -out) == 0) {
+ else if (strcmp(*argv, -out) == 0) {
if (--argc 1)
break;
outfile = *(++argv);
diff --git a/src/apps/dhparam.c b/src/apps/dhparam.c
index 3245e69..c35f902 100644
--- a/src/apps/dhparam.c
+++ b/src/apps/dhparam.c
@@ -159,7 +159,6 @@ dhparam_main(int argc, char **argv)
BIO *in = NULL, *out = NULL;
int informat, outformat, check = 0, noout = 0, C = 0, ret = 1;
char *infile, *outfile, *prog;
- char *inrand = NULL;
#ifndef OPENSSL_NO_ENGINE
char *engine = NULL;
#endif
@@ -217,11 +216,7 @@ dhparam_main(int argc, char **argv)
g = 2;
else if (strcmp(*argv, -5) == 0)
g = 5;
- else if (strcmp(*argv, -rand) == 0) {
- if (--argc 1)
- goto bad;
- inrand = *(++argv);
- } else if (((sscanf(*argv, %d, num) == 0) || (num = 0)))
+ else if (((sscanf(*argv, %d, num) == 0) || (num = 0)))
goto bad;
argv++;
argc--;
@@ -247,9 +242,6 @@ bad:
#ifndef OPENSSL_NO_ENGINE
BIO_printf(bio_err, -engine e use engine e, possibly a
hardware
device.\n); #endif
- BIO_printf(bio_err, -rand file:file:...\n);
- BIO_printf(bio_err,- load the file (or the
files in the
directory) into\n); -BIO_printf(bio_err,
Re: [PATCH 1/3] Check output of write() to stdout
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 correct fix is obvious.
Re: [PATCH 2/7] fix type string conversion warning
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/crypto/ts/ts_rsp_verify.c index 2a4c0c5..49754b5 100644 --- a/src/crypto/ts/ts_rsp_verify.c +++ b/src/crypto/ts/ts_rsp_verify.c @@ -564,7 +564,7 @@ TS_get_status_text(STACK_OF(ASN1_UTF8STRING) *text) ASN1_UTF8STRING *current = sk_ASN1_UTF8STRING_value(text, i); if (i 0) strlcat(result, /, length); - strlcat(result, ASN1_STRING_data(current), length); + strlcat(result, (const char *)ASN1_STRING_data(current), length); } return result; } What compiler warns about this? It's perfectly fine to pass a nonconst string to a function that takes a const string.
Re: exp2(3) bug?
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. (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
(amd64, sparc64, powerpc) return the expected result. So I'd say that
there is a bug in the i386-specific implementation of exp2(3).
And here is a fix. There actually isn't any i386-specific code, but
i386 is special and needs STRICT_ALIGN() to work properly for double
as well as float. FreeBSD made the same change a while ago:
http://svnweb.FreeBSD.org/base/head/lib/msun/src/math_private.h?revision=240827view=markup
You are quick. Thanks for figuring this out.
Ugh ... it was intentionally left broken as an optimization. That's crazy.
OK martynas@.
Haven't run the regression tests yet with this change.
Index: src/math_private.h
===
RCS file: /cvs/src/lib/libm/src/math_private.h,v
retrieving revision 1.16
diff -u -p -r1.16 math_private.h
--- src/math_private.h12 Nov 2013 20:35:09 - 1.16
+++ src/math_private.h2 Jun 2014 09:30:13 -
@@ -349,7 +349,7 @@ do {
\
#define STRICT_ASSIGN(type, lval, rval) do {\
volatile type __lval; \
\
- if (sizeof(type) = sizeof(double)) \
+ if (sizeof(type) = sizeof(long double))\
(lval) = (rval);\
else { \
__lval = (rval);\
Re: [PATCH] rcs: no way to go, after usage was called
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.
Re: pf anchor references
* 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 written, we had no clear idea where anchors would go and how people use them. That explains some functionality that is there today. But heck: now we DO know how they're being used, so let's get rid of the other parts where appropriate. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: [PATCH 2/7] fix type string conversion warning
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
Re: [PATCH 2/7] fix type string conversion warning
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 of the codebase, without causing accidental harm to the API. Each simplification step should make the code simpler, more accessibile for analysis by skilled peopke, resulting in further improvement; security will improve step-by-step hopefully without any other downsides. You can be part of that agenda. Or, we can go bikeshed about compiler warnings which are clearly false positives. Under the assumption that these conversations have no time-wasting impact on the people doing real work to make things better. You can figure out what I'm not saying on this line.
Re: [PATCH 2/7] fix type string conversion warning
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 that code is better without casts. The OpenSSL codebase is absolutely lousy with unnecessary and even harmful casts. They should be deleted before we start adding new casts.
Re: LibreSSL memory leak fix
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 --- src/lib/libssl/src/crypto/bio/bss_dgram.c 27 Apr 2014 20:26:48 - 1.25 +++ src/lib/libssl/src/crypto/bio/bss_dgram.c 2 Jun 2014 07:20:34 - @@ -1224,6 +1224,7 @@ dgram_sctp_ctrl(BIO *b, int cmd, long nu memcpy(authkey-sca_key[0], ptr, 64 * sizeof(uint8_t)); ret = setsockopt(b-num, IPPROTO_SCTP, SCTP_AUTH_KEY, authkey, sockopt_len); + free(authkey); if (ret 0) break;
ld.so malloc
Hi,
ld.so has a very basic malloc. This diff changes it to use a (somewhat
stripped) libc malloc with all the randomization and other goodness.
The diff has malloc, free and calloc, no realloc. A next sweep would
actually use calloc (and reallocarray) in ld.so. It currently only uses
malloc (with zero filling!), but there's room for improvement here.
I only tested this on sparc64. Please help and test this on various
platforms.
Keep a root shell and a copy of ld.so handy in case it blows up.
Thanks,
-Otto
Index: Makefile
===
RCS file: /cvs/src/libexec/ld.so/Makefile,v
retrieving revision 1.48
diff -u -p -r1.48 Makefile
--- Makefile28 May 2014 18:57:56 - 1.48
+++ Makefile2 Jun 2014 08:37:26 -
@@ -15,6 +15,8 @@ VPATH=${.CURDIR}/../../lib/libc/string
SRCS= ldasm.S boot.c loader.c resolve.c dlfcn.c dl_printf.c rtld_machine.c
SRCS+= path.c util.c sod.c strsep.c strtol.c dir.c library_subr.c dl_prebind.c
SRCS+= dl_realpath.c dl_uname.c dl_dirname.c strlcat.c strlen.c trace.c
+SRCS+= malloc.c
+
.if (${MACHINE_ARCH} == i386)
SRCS+= library_mquery.c
.else
Index: malloc.c
===
RCS file: malloc.c
diff -N malloc.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ malloc.c2 Jun 2014 12:35:48 -
@@ -0,0 +1,1022 @@
+/* $OpenBSD: malloc.c,v 1.166 2014/05/26 06:19:07 otto Exp $ */
+/*
+ * Copyright (c) 2008, 2010, 2011 Otto Moerbeek o...@drijf.net
+ * Copyright (c) 2012 Matthew Dempsky matt...@openbsd.org
+ * Copyright (c) 2008 Damien Miller d...@openbsd.org
+ * Copyright (c) 2000 Poul-Henning Kamp p...@freebsd.org
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+/*
+ * If we meet some day, and you think this stuff is worth it, you
+ * can buy me a beer in return. Poul-Henning Kamp
+ */
+
+
+#include sys/types.h
+#include sys/param.h
+#include sys/queue.h
+#include sys/mman.h
+#include sys/uio.h
+#include stdint.h
+#include string.h
+#include unistd.h
+
+#include archdep.h
+
+#if defined(__sparc__) !defined(__sparcv9__)
+#define MALLOC_PAGESHIFT (13U)
+#elif defined(__mips64__)
+#define MALLOC_PAGESHIFT (14U)
+#else
+#define MALLOC_PAGESHIFT (PAGE_SHIFT)
+#endif
+
+#define MALLOC_MINSHIFT4
+#define MALLOC_MAXSHIFT(MALLOC_PAGESHIFT - 1)
+#define MALLOC_PAGESIZE(1UL MALLOC_PAGESHIFT)
+#define MALLOC_MINSIZE (1UL MALLOC_MINSHIFT)
+#define MALLOC_PAGEMASK(MALLOC_PAGESIZE - 1)
+#define MASK_POINTER(p)((void *)(((uintptr_t)(p))
~MALLOC_PAGEMASK))
+
+#define MALLOC_MAXCHUNK(1 MALLOC_MAXSHIFT)
+#define MALLOC_MAXCACHE256
+#define MALLOC_DELAYED_CHUNK_MASK 15
+#define MALLOC_INITIAL_REGIONS 512
+#define MALLOC_DEFAULT_CACHE 64
+#defineMALLOC_CHUNK_LISTS 4
+
+/*
+ * When the P option is active, we move allocations between half a page
+ * and a whole page towards the end, subject to alignment constraints.
+ * This is the extra headroom we allow. Set to zero to be the most
+ * strict.
+ */
+#define MALLOC_LEEWAY 0
+
+#define PAGEROUND(x) (((x) + (MALLOC_PAGEMASK)) ~MALLOC_PAGEMASK)
+
+/*
+ * What to use for Junk. This is the byte value we use to fill with
+ * when the 'J' option is enabled. Use SOME_JUNK right after alloc,
+ * and SOME_FREEJUNK right before free.
+ */
+#define SOME_JUNK 0xd0/* as in Duh :-)
Re: nextafterl(3) possible bug
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 things. Not entirely happy with the fix though, so
I'm still thinking about improvements.
confirming that this patch fixes the failing numpy regress test on i386.
let me know if you want me to test a different diff.
Index: src/ld80/s_nextafterl.c
===
RCS file: /cvs/src/lib/libm/src/ld80/s_nextafterl.c,v
retrieving revision 1.4
diff -u -p -r1.4 s_nextafterl.c
--- src/ld80/s_nextafterl.c 12 Nov 2013 21:07:28 - 1.4
+++ src/ld80/s_nextafterl.c 2 Jun 2014 13:21:58 -
@@ -32,8 +32,8 @@ nextafterl(long double x, long double y)
ix = esx0x7fff;/* |x| */
iy = esy0x7fff;/* |y| */
- if (((ix==0x7fff)((hx|lx)!=0)) || /* x is nan */
- ((iy==0x7fff)((hy|ly)!=0))) /* y is nan */
+ if (((ix==0x7fff)((hx=0x7fff|lx)!=0)) || /* x is nan */
+ ((iy==0x7fff)((hy-0x7fff|ly)!=0))) /* y is nan */
return x+y;
if(x==y) return y; /* x=y, return y */
if((ix|hx|lx)==0) { /* x == 0 */
@@ -47,31 +47,50 @@ nextafterl(long double x, long double y)
if(ixiy||((ix==iy) (hxhy||((hx==hy)(lxly) {
/* x y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if (hx = 0x8000) {
+ if (esx == 0) {
+ --hx;
+ } else {
+ esx -= 1;
+ hx = hx - 1;
+ if (esx 0)
+ hx |= 0x8000;
+ }
+ } else
+ hx -= 1;
}
lx -= 1;
} else {/* x y, x += ulp */
lx += 1;
if(lx==0) {
hx += 1;
- if (hx==0)
+ if (hx==0 || (esx == 0 hx == 0x8000)) {
esx += 1;
+ hx |= 0x8000;
+ }
}
}
} else {/* x 0 */
if(esy=0||(ixiy||((ix==iy)(hxhy||((hx==hy)(lxly)){
/* x y, x -= ulp */
if(lx==0) {
- if (hx==0) esx -= 1;
- hx -= 1;
+ if (hx = 0x8000) {
+ esx -= 1;
+ hx = hx - 1;
+ if ((esx0x7fff) 0)
+ hx |= 0x8000;
+ } else
+ hx -= 1;
}
lx -= 1;
} else {/* x y, x += ulp */
lx += 1;
if(lx==0) {
hx += 1;
- if (hx==0) esx += 1;
+ if (hx==0 || (esx == 0x8000 hx == 0x8000)) {
+ esx += 1;
+ hx |= 0x8000;
+ }
}
}
}
Remove unnecessary patch to make IO::Compress look arch dependent
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 patch was added in installperl r1.25
http://www.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/perl/installperl#rev1.25
Over the weekend I sent the local patch to perl5-porters to see about
getting it imported upstream.
https://rt.perl.org/Public/Bug/Display.html?id=122001
After some discussion on p5p, the committer pointed to his commit that
reverted the perl changes that triggered the OpenBSD patch.
http://perl5.git.perl.org/perl.git/commit/88a6f4fc380d30c405f82eb0f2962237fd771fea
They reverted because IO::Compress stopped being architecture dependent.
Index: gnu/usr.bin/perl/installperl
===
RCS file: /cvs/src/gnu/usr.bin/perl/installperl,v
retrieving revision 1.28
diff -u -p -u -r1.28 installperl
--- gnu/usr.bin/perl/installperl24 Mar 2014 15:05:13 - 1.28
+++ gnu/usr.bin/perl/installperl3 Jun 2014 01:45:03 -
@@ -150,7 +150,7 @@ if ((-e testcompile) (defined($ENV{
}
# Exclude nonxs extensions that are not architecture dependent
-my @nonxs = grep(!/^(Errno|IO\/Compress)$/, split(' ', $Config{'nonxs_ext'}));
+my @nonxs = grep(!/^Errno$/, split(' ', $Config{'nonxs_ext'}));
my @ext_dirs = qw(cpan dist ext);
foreach my $ext_dir (@ext_dirs) {
