Hello,
In vi, cs_next() always returns zero so don't check its return value.
cs.cs_flags is always checked afterwards; cs.cs_flags seems to be
the effective return value.
I didn't change two invocations in v_word.c where cs_next() is 2nd
operand in && expression and might be skipped.
- Michael
this diff takes advantage of -msave-args to allow ddb to print
arguments in stack traces on amd64.
-msave-args basically pushes the functions register arguments onto
the stack, so the code looks before (in memory) the base pointer
for them. the rest of the arguments get passed normally, ie, after
On Wed, 26 Apr 2017 22:56:57 +0200, Christian Weisgerber wrote:
> The cases before and after follow the
>
> if (!interactive) {
> if (garrulous)
> ...
>
> pattern. *shrug*
Yes, but in this case there is nothing to do if !garrulous which
is differ
Todd C. Miller:
> > case FATAL:
> > - if (!interactive)
> > - fprintf(stderr, garrulous ?
> > - "script, line %d: %s\n" : "",
> > - lineno, errmsg);
> > - else
> >
On Wed, 26 Apr 2017 22:10:49 +0200, Christian Weisgerber wrote:
> This fixes the clang warnings in bin/ed. One extra pair of parentheses
> and stop passing empty format strings to printf-family functions.
One comment inline. Overall, I find the changes to be an improvement.
I see that FreeBSD b
This fixes the clang warnings in bin/ed. One extra pair of parentheses
and stop passing empty format strings to printf-family functions.
ok?
Index: glbl.c
===
RCS file: /cvs/src/bin/ed/glbl.c,v
retrieving revision 1.18
diff -u -p -r
> From: David Gwynne
> Date: Tue, 25 Apr 2017 11:06:52 +1000
>
> > On 25 Apr 2017, at 6:18 am, Mark Kettenis wrote:
> >
> >> Date: Mon, 24 Apr 2017 16:01:39 -0400
> >> From: Dale Rahn
> >>
> >> The below code is set up to attach and identify processors for arm64
> >> currently it only identif
> Date: Wed, 26 Apr 2017 14:56:58 +0100
> From: Stuart Henderson
>
> ok?
Sure.
> Index: etc/mtree/4.4BSD.dist
> ===
> RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
> retrieving revision 1.297
> diff -u -p -r1.297 4.4BSD.dist
> --- etc
The SSID element in beacons contains a length followed by the SSID value.
If an AP is configured to hide its SSID it sends a non-zero length SSID
which contains only zeroes:
tcpdump: listening on iwm0, link-type IEEE802_11_RADIO
15:53:46.250095 802.11 flags=0<>: beacon, \
caps=12021, \
ssid 0x
ok?
Index: etc/mtree/4.4BSD.dist
===
RCS file: /cvs/src/etc/mtree/4.4BSD.dist,v
retrieving revision 1.297
diff -u -p -r1.297 4.4BSD.dist
--- etc/mtree/4.4BSD.dist 18 Apr 2017 15:15:09 - 1.297
+++ etc/mtree/4.4BSD.dist
Sorry! The WebUI of gmail seems to screw with spaces in diffs.
Here is the Patch as a github gist:
https://gist.github.com/darinkes/9eb108e387e427dd35eae47f09877bfd
Greetz
Stefan
Hi,
This patch adds basic support for the no_proxy environment variable to the
ftp(1) tool.
So you can get files from internal servers, without unsetting
http/ftp_proxy env every time.
E.g.:
- no_proxy=internal.service.com ./ftp -o bla http://internal.service.com/foo
Also usage of asterisks as w
Thanks, fixed.
- todd
Hi,
actually you are right that this issue is related to control messages and not
to the send buffer length. But the length of the control message is checked in
combination with the data to be sent in uip_socket.c:
Let's assume we are sending data with the maximum send buffer size (e.g. 1024).
On 2017/04/26 00:47, Jeremie Courreges-Anglas wrote:
> "Ted Unangst" writes:
>
> > Jeremie Courreges-Anglas wrote:
> >>
> >> clang already recognizes (and ignores) -fforce-addr but errors out
> >> on -fno-force-addr. This breaks the build of ports/databases/qdbm:
> >>
> >>
> >> http://build
On Fri, Apr 14, 2017 at 12:26:22PM +0800, Michael W. Bombardieri wrote:
> Hi,
>
> Some printf() statements in vmm.c already used __func__
> but some didn't. This diff adds more __func__.
>
> Also, one printf() statement was missing a space:
>"vcpu_run_vmx: can't readprocbased ctls on exit"
>
16 matches
Mail list logo
