On Mon, Jul 21, 2014 at 06:59:12AM +, Doug Hogan wrote:
Make it clear what check implies for mallocarray. Thanks to dlg@ for
pointing this behavior out.
some take this, please.
jmc
Index: share/man/man9/malloc.9
===
BUF_MEM_free() only has one parameter and it returns immediately
if it is NULL.
Index: src/crypto/asn1/a_d2i_fp.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/asn1/a_d2i_fp.c,v
retrieving revision 1.11
diff -u -p -d -r1.11
On Mon, Jul 21, 2014 at 06:59:12AM +, Doug Hogan wrote:
-objects and checks for arithmetic overflow.
+objects and calls
+.Xr panic 9
+on arithmetic overflow.
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this
Anybody is using the -sa modifier of route(8)? A sockaddr in hexa,
really? What's your use case?
Otherwise, ok to kill it?
Index: keywords.h
===
RCS file: /home/ncvs/src/sbin/route/keywords.h,v
retrieving revision 1.28
diff -u -p
On 2014/07/22 11:01, Martin Pieuchot wrote:
Anybody is using the -sa modifier of route(8)? A sockaddr in hexa,
really? What's your use case?
That only seems useful in situations where modifying route(8) would
be a better choice..
Otherwise, ok to kill it?
Obviously wait for other
On Tue, Jul 22, 2014 at 10:06:35AM +0100, Stuart Henderson wrote:
On 2014/07/22 11:01, Martin Pieuchot wrote:
Anybody is using the -sa modifier of route(8)? A sockaddr in hexa,
really? What's your use case?
That only seems useful in situations where modifying route(8) would
be a better
Hi,
This is a second diff and it makes sure that pf_step_into_anchor always
saves a pointer to the rule that owns the anchor on the pf anchor stack.
There's no reason why we should check for depth here. As a side effect
this makes sure that the correct nested anchor gets it's counter bumped
Hello everybody,
I'm currently working on revamping dhcpd(8)'s configuration parser and
now that my work is almost complete, I would like to test it against
some configuration files to make sure that my parser and the one we have
in the tree do the same things. The weirder, the better!
Cheers,
When I added p2p_rtrequest() the RTF_LOCAL flag was not yet available, so
I used RTF_LLINFO to say that a route should be used for local trafic.
The diff below removes this hack and correctly check for RTF_LOCAL in
all the custom *_rtrequest() functions able to change the ifp of a route.
ok?
Martin Natano nat...@natano.net writes:
FSTAB has been deprecated in favor of _PATH_FSTAB in 4.4BSD. It's time
to let go of it. Below the diff I committed to Bitrig.
Make sense and looks innocuous to me, I'll commit it tomorrow unless
I hear objections.
Thanks,
cheers,
natano
Replace
Here's the last piece of information I'd like to *always* have in the
routing table in order to be able to replace the RB-tree.
This diff adds the configured broadcast addresses to the routing table
permanently. Actually these addresses are handled like lladdr and are
removed when their timeout
On 21 July 2014, Liviu Daia liviu.d...@gmail.com wrote:
On 12 July 2014, Stuart Henderson st...@openbsd.org wrote:
trace -
stopped at uao_reference+0x88: movq %rcx,0x8(%rax)
uao_reference at ..+0x88
uao_set_swslot at ..+0x55
uvmpd_scan_inactive at ..+0x681
uvmpd_scan at ..+0x23c
Sorry, let me split this into smaller diffs to ease review.
First up, the diff below removes a redundant cast: buf is declared a
char * so there's no need to cast it to a char *. I noticed the same
issue in ufs.c, too, so fix it in both places.
Index: ufs.c
Hi,
Before I send a diff for pfctl to disable once on match rules,
I've decided to try and see how much work is it to make it actually
work. Turns out that I need to extend pf_rule_item by 3 pointers
to track the match rule ruleset, anchor rule and the ruleset it
belongs to.
Here's what this
On Tue, Jul 22, 2014 at 3:52 AM, Grégoire Duchêne gduch...@awhk.org wrote:
Hello everybody,
I'm currently working on revamping dhcpd(8)'s configuration parser and
now that my work is almost complete, I would like to test it against
some configuration files to make sure that my parser and the
Next, use NULL instead of casting 0 to pointer types.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.22
diff -p -u -r1.22 ufs.c
--- sys/lib/libsa/ufs.c 30 May 2013 19:19:09
current used one is too simple :-( below
i must add some static root to this configuration but i didnt do it
, still somehow working on integration with pf and unbound (and other
less interesting stuff)
( please do not break the client ip insertion in pf table )
I am not sure it is even
Martin Natano nat...@natano.net writes:
FSTAB has been deprecated in favor of _PATH_FSTAB in 4.4BSD. It's time
to let go of it. Below the diff I committed to Bitrig.
cheers,
natano
Committed, thanks.
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Simplify if-conditions by removing explicit != 0.
Index: sys/lib/libsa/ufs.c
===
RCS file: /work/cvsroot/src/sys/lib/libsa/ufs.c,v
retrieving revision 1.24
diff -p -u -r1.24 ufs.c
--- sys/lib/libsa/ufs.c 22 Jul 2014 18:03:03 -
di_size is u_int64_t in both struct ufs1_dinode and ufs2_dinode, and
strlen returns size_t. Adjust link_len and len declarations to match
and drop now-redundant unsigned cost from bcopy.
Index: sys/lib/libsa/ufs.c
===
RCS file:
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this instead:
Hmm I think it's only misleading in the M_CANFAIL case. I think this
diff makes it a
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote:
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this instead:
Hmm I think it's only misleading in the
On Tue, Jul 22, 2014 at 21:21, Doug Hogan wrote:
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this instead:
Hmm I think it's only misleading in the
Date: Tue, 22 Jul 2014 21:21:39 +
From: Doug Hogan d...@acyclic.org
On Tue, Jul 22, 2014 at 02:51:17AM -0400, Jean-Philippe Ouellet wrote:
That is misleading in the M_CANFAIL case.
I'm not terribly good at wording things, but I suggest something
more like this instead:
Hmm I
On Wed, Jul 23, 2014 at 00:02, Mark Kettenis wrote:
Hmm, I believe, quite strongly, that we should always panic when a
arithmetic overflow is detected.
The M_CANFAIL flag is really there to allow for failure in certain
low-memory conditions, not to recover from programming bugs.
The
Was just investigating a little issue with a long running (stuck)
process. I logged in at 9:20PM:
10002 0.0 0.0 3740 2420 ?? S 9:20PM0:00.02 sshd
So you can imagine my surprise to see a cron job running in the future:
24292 0.0 0.0 776 616 ?? Is 9:25PM0:08.51
XETCLIST=`mktemp /tmp/_xetcsum.XX` || exit 1; sort
distrib/sets/lists/xetc/{mi,md.amd64} ${XETCLIST}; cd /usr/xf4-dest
xargs sha256 -h /usr/xf4-dest/usr/share/sysmerge/xetcsum ${XETCLIST} || true;
rm -f ${XETCLIST}
cd distrib/sets env MACHINE=amd64 ksh ./maketars 56 5.6 { env
Indeed. fixed.
Penned by Ian Mcwilliam on 20140722 21:18.12, we have:
| XETCLIST=`mktemp /tmp/_xetcsum.XX` || exit 1; sort
distrib/sets/lists/xetc/{mi,md.amd64} ${XETCLIST}; cd /usr/xf4-dest
xargs sha256 -h /usr/xf4-dest/usr/share/sysmerge/xetcsum ${XETCLIST} || true;
rm -f
28 matches
Mail list logo
