[patch] user/6104: newsyslog count off by one

Hello, Please review the proposed patch to fix the newsyslog problem. Thanks, David $ diff -u newsyslog.c newsyslog.c.bak --- newsyslog.c.bak Thu Oct 22 21:18:12 2009 +++ newsyslog.c Thu Oct 22 22:00:09 2009 @@ -756,6 +756,9 @@ char file1[MAXPATHLEN], file2[MAXPATHLEN], *suffix;

Accessoires de mode soldé jusqu'a -70%

Ce message contient des images, si elles ne s'affichent pas correctement, cliquez ici [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] Nos clientes t

Re: if_loop

On Fri, Jan 8, 2010 at 9:15 PM, Claudio Jeker wrote: > > On Fri, Jan 08, 2010 at 01:06:03AM -0300, Gleydson Soares wrote: > >> i guess that if ifp might be bpf attached in loop_clone_create() it should be detached case destroyed. > >> Index: if_loop.c > >> =

Re: [patch] patch:util.c does free memory after strdup(3)

Stuart Henderson wrote: > On 2010/01/08 13:33, Owain Ainsworth wrote: >> Please note that none of your patches apply because of spaces in the >> whitespace instead of tabs (I applied them manually). Either your mail >> client is mangling the diffs, or you're copy/pasting the diffs into the >> mail

Re: if_loop

On Fri, Jan 08, 2010 at 01:06:03AM -0300, Gleydson Soares wrote: > i guess that if ifp might be bpf attached in loop_clone_create() it should be > detached case destroyed. > Index: if_loop.c > === > RCS file: /cvs/src/sys/net/if_loop.

Re: [patch] lib/libc/yp/yp_all.c mem leak

On Fri, Jan 8, 2010 at 2:22 PM, patrick keshishian wrote: > On Fri, Jan 08, 2010 at 03:47:48PM +0300, Igor Zinovik wrote: >> Hello, t...@. >> >> A bit tricky code in yp_all.c `val' is not freed. It might be >> allocated but might be not freed >> when `key' allocation failed. >> >> Index: lib/li

Re: [patch] lib/libc/yp/yp_all.c mem leak

On Fri, Jan 08, 2010 at 03:47:48PM +0300, Igor Zinovik wrote: > Hello, t...@. > > A bit tricky code in yp_all.c `val' is not freed. It might be > allocated but might be not freed > when `key' allocation failed. > > Index: lib/libc/yp/yp_all.c > =

Re: [patch] patch:util.c does free memory after strdup(3)

2010/1/8 Stuart Henderson : > On 2010/01/08 13:33, Owain Ainsworth wrote: >> Please note that none of your patches apply because of spaces in the >> whitespace instead of tabs (I applied them manually). Either your mail >> client is mangling the diffs, or you're copy/pasting the diffs into the >> m

Re: [patch] patch:util.c does free memory after strdup(3)

On 2010/01/08 13:33, Owain Ainsworth wrote: > Please note that none of your patches apply because of spaces in the > whitespace instead of tabs (I applied them manually). Either your mail > client is mangling the diffs, or you're copy/pasting the diffs into the > mail client. In future could you pl

Bar Magazine Tip of the Week

Private Label Bar Mix Helps Small-Mid Sized Chains Improve Quality and Consistency Signature drinks and Private Labeling are powerful marketing tools to increase Quality and Consistency - 2 ingredients which help to drive sales and boost profits. Many small to medium-sized restaurants feel it is

Re: [patch] patch:util.c does free memory after strdup(3)

On Fri, Jan 08, 2010 at 12:45:11AM +0300, Igor Zinovik wrote: > Hello, t...@. > > tmpbuf is allocated via strdup(3) but it is leaved unfreed when we > leave makedirs() function. I have commited a few of these (this one, the libc/hash one and the pwd_mkdb one). I shall look at the others shortly

[patch] lib/libc/yp/yp_all.c mem leak

Hello, t...@. A bit tricky code in yp_all.c `val' is not freed. It might be allocated but might be not freed when `key' allocation failed. Index: lib/libc/yp/yp_all.c === RCS file: /OpenBSD/src/lib/libc/yp/yp_all.c,v retrieving re

[patch] dhcpd/confpars.c tiny memory leak

Hello, t...@. dhcpd forgets to free(3) host. Index: usr.sbin/dhcpd/confpars.c === RCS file: /OpenBSD/src/usr.sbin/dhcpd/confpars.c,v retrieving revision 1.18 diff -u -r1.18 confpars.c --- usr.sbin/dhcpd/confpars.c 2 Jan 2010 04:2

Re: Automatic package mirror discovery implementation for pkg_add(1) tool

2010/1/8 Bob Beck : >> Apart from this, this is a really tough problem, because of infrastructure >> issues. Basically, our mirrors are not that reliable, and the closest >> one often won't have the packages you need... which is a reason why it's >> mostly some user settings... > > True - although

Re: Automatic package mirror discovery implementation for pkg_add(1) tool

> Apart from this, this is a really tough problem, because of infrastructure > issues. Basically, our mirrors are not that reliable, and the closest > one often won't have the packages you need... which is a reason why it's > mostly some user settings... True - although we could do a very similar

[patch] /usr/src/lib/libc/hash/helper.c

Hello, t...@. HASHFileChunk leaks file descriptor `fd'. Index: lib/libc/hash/helper.c === RCS file: /OpenBSD/src/lib/libc/hash/helper.c,v retrieving revision 1.8 diff -u -r1.8 helper.c --- lib/libc/hash/helper.c 8 Aug 2005 08: