On Fri, Jul 11, 2014 at 05:46:15AM +, Doug Hogan wrote:
> I don't think the current man page has enough detail for what the
> malloc.conf settings do.
>
>
> Index: lib/libc/stdlib/malloc.3
> ===
> RCS file: /cvs/src/lib/libc/stdl
Csh has a section of code where it NUL terminates after a strlcpy().
Strlcpy() may read past what readlink() wrote since readlink() does
not append a NUL.
Index: bin/csh/dir.c
===
RCS file: /cvs/src/bin/csh/dir.c,v
retrieving revisio
On Thu, 10 Jul 2014 23:17:44 -0400, Daniel Dickman wrote:
>>> For some urls, lynx will invoke an external command. Turn off telnet,
>>> rlogin and tn3270 urls by defining them to false(1) as documented in the
>>> lynx manual.
>>
>> Gopher and NNTP are actually still being used (the former a bit
>>
I don't think the current man page has enough detail for what the
malloc.conf settings do.
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.78
diff -u -p -d -r1.78 malloc.3
--- l
socket() returns -1 on error.
Index: usr.sbin/smtpd/table_socketmap.c
===
RCS file: /cvs/src/usr.sbin/smtpd/table_socketmap.c,v
retrieving revision 1.4
diff -u -p -d -r1.4 table_socketmap.c
--- usr.sbin/smtpd/table_socketmap.c8 J
On Jul 10, 2014, at 8:05 PM, Daniel Dickman wrote:
> Patch below turns off the following ancient protocols built into lynx:
> bibp, finger, gopher, and news.
>
> For some urls, lynx will invoke an external command. Turn off telnet,
> rlogin and tn3270 urls by defining them to false(1) as docu
On 07/10/14 23:05, Daniel Dickman wrote:
Patch below turns off the following ancient protocols built into lynx:
bibp, finger, gopher, and news.
For some urls, lynx will invoke an external command. Turn off telnet,
rlogin and tn3270 urls by defining them to false(1) as documented in the
lynx manu
Pretty standard thing in several companies I do work for is to have an intranet
page with http://, ssh://, telnet:// and finger:// (amazingly) links to various
devices on the network. Having to read the source and escape to a shell would
be somewhat worse than what I get on a base install today
> On Jul 10, 2014, at 11:50 PM, Adam Thompson wrote:
>
> As a user, not a developer...
> I still use finger, gopher, and news URLs at least once a year each. As a
> user, I disagree with turning support for those schemes off completely.
> Finger and news I can use another tool, and I'd concede
As a user, not a developer...
I still use finger, gopher, and news URLs at least once a year each. As a
user, I disagree with turning support for those schemes off completely.
Finger and news I can use another tool, and I'd concede that no-one really
*needs* a news reader in base. (I still find
On 07/10/14 23:17, Daniel Dickman wrote:
For some urls, lynx will invoke an external command. Turn off telnet,
rlogin and tn3270 urls by defining them to false(1) as documented in the
lynx manual.
Gopher and NNTP are actually still being used (the former a bit
sparsely, but there are a few serv
>> For some urls, lynx will invoke an external command. Turn off telnet,
>> rlogin and tn3270 urls by defining them to false(1) as documented in the
>> lynx manual.
>
> Gopher and NNTP are actually still being used (the former a bit
> sparsely, but there are a few servers here and there). The rest
On Thu, 2014-07-10 at 23:05 -0400, Daniel Dickman wrote:
> Patch below turns off the following ancient protocols built into lynx:
> bibp, finger, gopher, and news.
>
> For some urls, lynx will invoke an external command. Turn off telnet,
> rlogin and tn3270 urls by defining them to false(1) as d
Patch below turns off the following ancient protocols built into lynx:
bibp, finger, gopher, and news.
For some urls, lynx will invoke an external command. Turn off telnet,
rlogin and tn3270 urls by defining them to false(1) as documented in the
lynx manual.
Finally, turn off the file editor w
This is a fix for OpenSSL tickets #977 and #3213, loosely based on patch from
Reuben Thomas from #3213.
---
src/apps/s_client.c |5 +++--
src/apps/s_server.c | 10 ++
src/apps/s_time.c |5 +++--
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/src/apps/s_client.c
Hi,
> Both diffs applied, thanks!
thx!
> Even though we are seriously considering removing the srp code
> altogether, it does not hurt to make things better, one bug at a time.
I guess I'd appreciate keeping it, we are using it in production, though
not directly with SSL, that's where the patch
On 07/10/14 18:38, Claudio Jeker wrote:
> I was looking for something like this. Manly to make dump -W work with
> DUIDs. Would be nice if it would not introduce a new flag but I think I
> can live with that if the rest works.
How would you decide whether to use the file name or the duid then? I
c
On 11 Jul 2014, at 9:48, Brad Smith wrote:
> On 10/07/14 1:33 AM, David Gwynne wrote:
>> this is an update of if_sk.c r1.151, which tried to introduce
>> mclgeti. it updates it to use the if_rxring accounting.
>>
>> does anyone have one they can test this on?
>>
>> it also saves about 2k on am
On 10/07/14 1:33 AM, David Gwynne wrote:
this is an update of if_sk.c r1.151, which tried to introduce
mclgeti. it updates it to use the if_rxring accounting.
does anyone have one they can test this on?
it also saves about 2k on amd64.
Doesn't work at all.
skc0 at pci0 dev 5 function 0 "Schn
On 07/10/14 16:28, Alexander Hall wrote:
> Anyway, I worked on your diff a bit more:
>
> - keep having -U and -u separate (as discussed)
> - use Uflag instead of duidflag
> - bail out if the duid is all 0.
> - allow specifying the drive to dump by . on the
> command line. Subject to race conditi
On Thu, Jul 10, 2014 at 01:42:21PM -0700, Matthew Dempsky wrote:
> No, Bl's "-width" option is used to specify how much padding should be
> used to align the list entry text when mandoc, and MAP_ANONYMOUS is
> the widest map flag (other than MAP_HASSEMAPHORE, which I'm hoping
> goes away soon anywa
> On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
> >
> > Modified files:
> > usr.bin/rdist : common.c config-data.h
> >
> > Log message:
> > Assume POSIX: w
On Thu, Jul 10, 2014 at 08:29:04AM -0600, Philip Guenther wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: guent...@cvs.openbsd.org2014/07/10 08:29:03
>
> Modified files:
> usr.bin/rdist : common.c config-data.h
>
> Log message:
> Assume POSIX: write() takes size_t
I question the extent to which this micro optimization really matters,
given that the code would eventually be compressed, but...
Make the code simpler by only having one copy, but outlining on small
kernels. This makes things even smaller. No change for normal kernels,
but small ones shrink from
> On Thu, Jul 10, 2014 at 11:50:18AM -0700, Matthew Dempsky wrote:
> > Diff below defines MAP_ANONYMOUS as a synonym for MAP_ANON, keeping
> > MAP_ANON as canonical in following BSD heritage.
>
> If MAP_ANON is going to be the canonical value then shouldn't you
> change MAP_PRIVATE to MAP_ANON ins
On Thu, Jul 10, 2014 at 11:50:18AM -0700, Matthew Dempsky wrote:
> Diff below defines MAP_ANONYMOUS as a synonym for MAP_ANON, keeping
> MAP_ANON as canonical in following BSD heritage.
If MAP_ANON is going to be the canonical value then shouldn't you
change MAP_PRIVATE to MAP_ANON instead of MAP_
On Thu, Jul 10, 2014 at 1:20 PM, Ted Unangst wrote:
> Thoughts?
Seems kind of hacky to me, but if it results in significant
performance improvements in real world uses, then I could be swayed
since it's not very intrusive either.
On Thu, Jul 10, 2014 at 1:17 PM, Kent R. Spillner wrote:
> If MAP_ANON is going to be the canonical value then shouldn't you
> change MAP_PRIVATE to MAP_ANON instead of MAP_ANONYMOUS in mmap.2?
No, Bl's "-width" option is used to specify how much padding should be
used to align the list entry tex
Both diffs applied, thanks!
Even though we are seriously considering removing the srp code
altogether, it does not hurt to make things better, one bug at a time.
Miod
> Date: Thu, 10 Jul 2014 11:50:18 -0700
> From: Matthew Dempsky
>
> The Austin Group this morning accepted proposed wording to standardize
> both MAP_ANON and MAP_ANONYMOUS, recognizing that neither was clearly
> more popular than the other among applications, and that there's
> precedent in POSI
I'm not really expecting tun to provide blistering performance, but
one of the things that keeps it slower than need be is the one packet
per read/write implementation. It'd be pretty cool to have
something like readv() or writev() provide the ability to operate on
multiple packets at once. Unfortu
This diff adds another struct between filedesc and file to store
process-local per-descriptor information. Currently, the only thing in
this struct is the file pointer and some flags, however I have another
patch on top of this that adds capsicum capabilities to it. (And
another that uses mallocarr
---
src/crypto/srp/srp_lib.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/crypto/srp/srp_lib.c b/src/crypto/srp/srp_lib.c
index 0875b29..932fe63 100644
--- a/src/crypto/srp/srp_lib.c
+++ b/src/crypto/srp/srp_lib.c
@@ -80,6 +80,7 @@
static BIGNU
---
src/crypto/srp/srp_lib.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/crypto/srp/srp_lib.c b/src/crypto/srp/srp_lib.c
index 15e751c..0875b29 100644
--- a/src/crypto/srp/srp_lib.c
+++ b/src/crypto/srp/srp_lib.c
@@ -256,7 +256,7 @@ BIGNUM *SRP_Calc_A(BIGNUM
On Thu, Jul 10, 2014 at 12:34 PM, Jean-Philippe Ouellet
wrote:
> 2nd one should be mallocarray.
Doh, fixed. Thanks!
On Thu, Jul 10, 2014 at 12:02:40PM -0700, Matthew Dempsky wrote:
> -.Fn malloc "unsigned long size" "int type" "int flags"
> +.Fn malloc "size_t size" "int type" "int flags"
> +.Ft void *
> +.Fn malloc "size_t nmemb" "size_t size" "int type" "int flags"
2nd one should be mallocarray.
On Thu, Jul 10, 2014 at 12:02, Matthew Dempsky wrote:
> + panic("overflow");
Print the sizes here and ok with me.
panic("reallocarray overflow: %zu * %zu", num, size);
On Thu, Jul 10, 2014 at 02:42:34PM -0400, Ted Unangst wrote:
> On Thu, Jul 10, 2014 at 10:28, Matthew Dempsky wrote:
> > We've found a bunch of uses for reallocarray() in userland, and I
> > think the idiom is worth reusing in the kernel. There are enough
> > places where we do malloc(x * y) that
I saw this was already committed, but one tiny consistency nit inline below.
On Tue, Jul 08, 2014 at 05:11:22PM +0200, Henning Brauer wrote:
> I'll need this for some upcoming changes, at least to do it WITHOUT
> adding the 3rd or 4th or 5th copy of the bpf_mtap loop. most of these
> bpf_mtap_* ar
The Austin Group this morning accepted proposed wording to standardize
both MAP_ANON and MAP_ANONYMOUS, recognizing that neither was clearly
more popular than the other among applications, and that there's
precedent in POSIX for simply standardizing multiple spellings for a
feature when both are co
On Thu, Jul 10, 2014 at 10:28, Matthew Dempsky wrote:
> We've found a bunch of uses for reallocarray() in userland, and I
> think the idiom is worth reusing in the kernel. There are enough
> places where we do malloc(x * y) that I think it makes sense to add
> mallocarray(x, y).
> +void *malloc(u
Ping.
On Thu, May 01, 2014 at 01:22:56PM -0500, Kent R. Spillner wrote:
> After sending my previous reply I noticed that you already committed
> your diff, so here are my comments again in the form of a proper diff:
>
> * Use NULL instead of casting 0 to pointer types
>
> * Remove unnecessary (c
Ping.
On Wed, Jun 04, 2014 at 10:01:12AM -0500, Kent R. Spillner wrote:
> 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,
Hello all,
I use rdomains to split routing domains per company and also separate
administration interfaces from routing interfaces on my routers (sshd,
bacula, postfix and puppetd running on a dedicated rdomain)
Actually there is a problem with rdomains, we need to modify /etc/rc.d
scripts to add
On Thu, Jul 10, 2014 at 10:28:35AM -0700, Matthew Dempsky wrote:
> +/*
> + * This is sqrt(SIZE_MAX+1), as s1*s2 <= SIZE_MAX
> + * if both s1 < MUL_NO_OVERFLOW and s2 < MUL_NO_OVERFLOW
> + */
> +#define MUL_NO_OVERFLOW (1UL << (sizeof(size_t) * 4))
> +
> +void *
> +mallocarray(unsigned long nme
We've found a bunch of uses for reallocarray() in userland, and I
think the idiom is worth reusing in the kernel. There are enough
places where we do malloc(x * y) that I think it makes sense to add
mallocarray(x, y).
ok?
Index: share/man/man9/Makefile
===
On Thu, Jul 10, 2014 at 04:28:49PM +0200, Alexander Hall wrote:
> On 07/09/14 23:44, Alexander Hall wrote:
>
> > While looking at this, I noticed we don't support specifying the duid
> > for the device to dump. Thinking a bit more, I'm forming a different
> > approach for this. Hold on.
>
> Hm,
On 07/09/14 23:44, Alexander Hall wrote:
> While looking at this, I noticed we don't support specifying the duid
> for the device to dump. Thinking a bit more, I'm forming a different
> approach for this. Hold on.
Hm, the "different approach" was left out because of the messy argument
parsing.
On 2014-07-10, Henning Brauer wrote:
>> 1. Zero the protocol checksum.
>
> that should not be needed. at least afair.
Indeed, we'll overwrite it with the pseudo-header checksum anyway.
--
Christian "naddy" Weisgerber na...@mips.inka.de
/sbin:
diff --git sbin/Makefile.inc sbin/Makefile.inc
index 1b14860..92ca312 100644
--- sbin/Makefile.inc
+++ sbin/Makefile.inc
@@ -2,3 +2,4 @@
BINDIR?= /sbin
LDSTATIC= ${STATIC}
+CFLAGS+= -Werror-implicit-function-declaration
diff --git sbin/disklabel/editor.c sbin/disklabel/
Using -Werror-implicit-function-declaration in more places would be
very nice, though of course it breaks the build where the src tree is
not ready yet.
Sprinkling this option in a few more directories and either
identiyfing what works, or sending patches for what doesn't, would be
a great help. :
* Paul de Weerd [2014-07-10 14:33]:
> On Thu, Jul 10, 2014 at 01:30:29PM +0100, Stuart Henderson wrote:
> | On 2014/07/10 13:11, Henning Brauer wrote:
> | > I committed the bpf chunk, but nothing is using it yet. pls give the
> | > if_vlan.c chunk a spin.
> | I think weerd@ might need something si
* Stuart Henderson [2014-07-10 14:30]:
> On 2014/07/10 13:11, Henning Brauer wrote:
> > I committed the bpf chunk, but nothing is using it yet. pls give the
> > if_vlan.c chunk a spin.
> I think weerd@ might need something similar for bridge for his tv...
the f&^(*$@&)($#@ bridge needs to die. I
On Thu, Jul 10, 2014 at 01:30:29PM +0100, Stuart Henderson wrote:
| On 2014/07/10 13:11, Henning Brauer wrote:
| > I committed the bpf chunk, but nothing is using it yet. pls give the
| > if_vlan.c chunk a spin.
|
| I think weerd@ might need something similar for bridge for his tv...
I'm testing
On 2014/07/10 13:11, Henning Brauer wrote:
> I committed the bpf chunk, but nothing is using it yet. pls give the
> if_vlan.c chunk a spin.
I think weerd@ might need something similar for bridge for his tv...
> Index: net/if_vlan.c
> ===
I committed the bpf chunk, but nothing is using it yet. pls give the
if_vlan.c chunk a spin.
Index: net/if_vlan.c
===
RCS file: /cvs/src/sys/net/if_vlan.c,v
retrieving revision 1.106
diff -u -p -r1.106 if_vlan.c
--- net/if_vlan.c
On Thu, 10 Jul 2014 10:17:29 +0200 (CEST)
YASUOKA Masahiko wrote:
> On Wed, 9 Jul 2014 16:57:44 +0200
> Kenneth Westerback wrote:
>> On 9 July 2014 16:23, YASUOKA Masahiko wrote:
>>> Some users of npppd(8) want to use dhcpd(8) on tunneling interface to
>>> provide additional routing entries and
No need to cast int args to memcpy.
Index: asn1/a_bitstr.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_bitstr.c,v
retrieving revision 1.17
diff -u -p -r1.17 a_bitstr.c
--- asn1/a_bitstr.c 12 Jun 2014 15:49:27 - 1.
* Lawrence Teo [2014-07-10 06:14]:
> This diff does the following for reinjected packets:
>
> 1. Zero the protocol checksum.
that should not be needed. at least afair.
> 2. Set the checksum flag in pkthdr.
> 3a. For outbound packets, let the stack take care of the checksum.
i like.
might be
On Mon, Jun 23, 2014 at 06:46:27AM -0700, Matthew Dempsky wrote:
> I did this mostly for fun / personal enlightenment, so I haven't put
> too much effort into polishing it yet.
I got some positive feedback about the direction of this diff, so
tonight I finally got around to polishing it some more.
On Wed, 9 Jul 2014 16:57:44 +0200
Kenneth Westerback wrote:
> On 9 July 2014 16:23, YASUOKA Masahiko wrote:
>> Some users of npppd(8) want to use dhcpd(8) on tunneling interface to
>> provide additional routing entries and so on to VPN clients. So I'd
>> like to make the dhcpd work on the DLT_L
61 matches
Mail list logo
