On Mon, Sep 05, 2016 at 06:02:51PM -0400, Michael Reed wrote:
> I find that keeping prose at a different indentation level than source
> code makes the man page easier to read. Besides, it's already done
> in most other man pages.
>
fixed, thanks.
jmc
>
>
> Index: acme-client.1
>
On Mon, Sep 05, 2016 at 04:39:49PM -0400, Anthony Coulter wrote:
>
> While I vaguely remember reading long ago that `echo' and `[' were
> shell builtins, I'm much more strongly aware that /bin/echo and /bin/[
> are also available as separate executables. Their man pages don't
> mention that they h
This is likely to change, in some way. It is left this way to get
feedback on how it is used. Small steps. Thanks for the feedback :-)
>So people don't have to look in the source code.
>
>
>Index: doas.conf.5
>===
>RCS file: /cvs/sr
this gives us back 5k on amd64.
ok?
Index: ip_ipsp.c
===
RCS file: /cvs/src/sys/netinet/ip_ipsp.c,v
retrieving revision 1.214
diff -u -p -r1.214 ip_ipsp.c
--- ip_ipsp.c 23 May 2015 12:38:53 - 1.214
+++ ip_ipsp.c 6 Sep 20
this moves 80211 over to using the function version of red-black
trees. it gives us back the 2.5k of code that RB_GENERATE adds.
ok?
Index: ieee80211_ioctl.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_ioctl.c,v
retrieving revision
now that all the pools set an ipl we dont have to support optional ipls.
the ioff argument is and has been unused for many years, so this
replaces it with an ipl argument. cos the ipl is set on init, we
no longer need pool_setipl.
most of semantic changes in diff has been done with coccinelle usi
Ok, so I'll throw in my view too.
On September 5, 2016 1:24:17 PM GMT+02:00, Anthony Coulter
wrote:
>Some of the system scripts make inconsistent use of ksh-specific
>features, specifically "print" and "[[" as efficient replacements for
>"echo" and "[". This change makes the /etc/ksh.kshrc and a
I find that keeping prose at a different indentation level than source
code makes the man page easier to read. Besides, it's already done
in most other man pages.
Index: acme-client.1
===
RCS file: /cvs/src/usr.sbin/acme-client/acm
As is done in other man pages.
===
RCS file: /cvs/src/usr.sbin/sysmerge/sysmerge.8,v
retrieving revision 1.78
diff -u -p -r1.78 sysmerge.8
--- sysmerge.8 2 Sep 2016 12:17:33 - 1.78
+++ sysmerge.8 5 Sep 2016 21:54:28 -
> You don't explain why `print' is more efficient than `echo'.
Short answer: I'm an idiot who didn't realize that `echo' and `[' are
shell builtins. The only parts of my change that still seem worthwhile
to me now are the ones related to the awkward X-comparisons, but there
are few enough of those
So people don't have to look in the source code.
Index: doas.conf.5
===
RCS file: /cvs/src/usr.bin/doas/doas.conf.5,v
retrieving revision 1.30
diff -u -p -r1.30 doas.conf.5
--- doas.conf.5 2 Sep 2016 18:12:30 - 1.30
+++ doa
On Sun, Sep 04, 2016 at 02:25:06PM +0200, Martin Pieuchot wrote:
> >- One bug still left: when the device is attached after X has started,
> > it seems the scaling is done wrongly. I had this problem with the
> > hacked ums driver as well. Most of the time it is fixed by switching
> > between co
Hi,
Anthony Coulter writes:
> Some of the system scripts make inconsistent use of ksh-specific
> features, specifically "print" and "[[" as efficient replacements for
> "echo" and "[". This change makes the /etc/ksh.kshrc and all the rc
> scripts use "print" and "[[" exclusively.
You don't exp
2016-09-05 20:11 GMT+02:00 :
> The fact that one particular system still boots is not "good enough here".
>
> Kind regards,
> Anton
>
That's why he share his work. So other people can try on other system.
--
Cordialement, Coues Ludovic
+336 148 743 42
Mon, 5 Sep 2016 07:24:17 -0400 (EDT) Anthony Coulter
> Some of the system scripts make inconsistent use of ksh-specific
> features, specifically "print" and "[[" as efficient replacements for
> "echo" and "[". This change makes the /etc/ksh.kshrc and all the rc
> scripts use "print" and "[[" exclu
Some of the system scripts make inconsistent use of ksh-specific
features, specifically "print" and "[[" as efficient replacements for
"echo" and "[". This change makes the /etc/ksh.kshrc and all the rc
scripts use "print" and "[[" exclusively.
Switching from echo to print only brought up one inte
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.486
diff -u -p -r1.486 rc
--- rc 10 Jul 2016 09:08:18 - 1.486
+++ rc 5 Sep 2016 15:45:09 -
@@ -490,7 +490,6 @@ echo clearing /tmp
# rc.securelevel did not
Currently in mg, if you have a paragraph:
123
456
With the cursor on either the 4, 5 or 6 and no newline after the '6',
and then execute forward-paragraph (M-}), the cursor sits still and
does not move to the end of second line (after the 6), which is in
effect the end of parapraph. This diff fix
Hey, the typedef came in handy :) Ok bcook@
> On Sep 5, 2016, at 11:52 AM, Bob Beck wrote:
>
> I am in agreement in principle, but please coordinate with bcook@ and/or
> jsing@ who were possibly doing
> some related adjustments.
>
>
>
>> On Mon, Sep 5, 2016 at 4:44 AM, Ted Unangst wrote:
>
On Sun, 04 Sep 2016 20:40:47 -0600, "Anthony J. Bentley" wrote:
> eqnchar is a collection of eqn(7) definitions to create mathematical
> symbols by constructing them from other characters. Creating circled
> plus with O, a backspace, and a plus, for example. The results are
> quite ugly in both ma
On Mon, 05 Sep 2016 04:02:47 -0400, "Ted Unangst" wrote:
> Todd C. Miller wrote:
> > On Sun, 04 Sep 2016 11:58:23 -0600, "Anthony J. Bentley" wrote:
> >
> > > This brings /usr/share/misc/getopt in sync with the example in getopt(3).
> >
> > OK, though I wonder if anyone actually looks at this fi
>I am curious though - is dhclient really the right place to fix this? I
>might use some other dhcp client (dhcpcd in ports for example) or some
>other application that uses BPF. Should every userland program using BPF
>have to worry whether or not it is breaking bridging?
Various solutions are
Thanks for the explanation.
I am curious though - is dhclient really the right place to fix this? I
might use some other dhcp client (dhcpcd in ports for example) or some
other application that uses BPF. Should every userland program using BPF
have to worry whether or not it is breaking bridging
Hi all
thank you for including the feature.
I'm testing with my usecase and will report
back if strange things happen.
Thanks again and best regards
-Tobias
On 04.09.2016, at 12:28, Bob Beck wrote:
>
> On Sun, Sep 04, 2016 at 05:26:24AM -0500, Brent Cook wrote:
>> On Sun, Sep 04, 2016
I am in agreement in principle, but please coordinate with bcook@ and/or
jsing@ who were possibly doing
some related adjustments.
On Mon, Sep 5, 2016 at 4:44 AM, Ted Unangst wrote:
> Bob Beck wrote:
> > >
> > > Agreed, I was also a bit unclear on payload at first (though it grew on
> > > me ov
Bob Beck wrote:
> >
> > Agreed, I was also a bit unclear on payload at first (though it grew on
> > me over time, so I didn't change it). Here's an update with the
> > parameter renamed and better documented.
> >
> > ok?
>
> Yeah. I'm good with this
>
> IMO get it in so we can tweak it in tree.
It seems we're sticking with the C memcpy for a while (which does the bounds
check and logging) but now we're missing out on the potential asm speedup.
Let's try the best of both worlds by having the C memcpy call into memmove.
Yes, it'll do another direction test, but then it will go zip zoom fast
Hi Anthony,
Anthony J. Bentley wrote on Sun, Sep 04, 2016 at 08:40:47PM -0600:
> eqnchar is a collection of eqn(7) definitions to create mathematical
> symbols by constructing them from other characters. Creating circled
> plus with O, a backspace, and a plus, for example. The results are
> quite
On Mon, Sep 05, 2016 at 04:04:23AM -0400, Ted Unangst wrote:
> Sevan Janiyan wrote:
> > Hello,
> > Attached patches remove the main() prototype from
> > src/{sbin,usr.bin,usb.sbin}
>
> yes!
I'm 100% certain I added those prototypes because some version of gcc
with the appropriate warning flags wo
Are you retarded ?
Go study the source code.
Hi,
Anthony J. Bentley wrote on Mon, Sep 05, 2016 at 02:05:57AM -0600:
> "Ted Unangst" writes:
>> Todd C. Miller wrote:
>>> On Sun, 04 Sep 2016 11:58:23 -0600, "Anthony J. Bentley" wrote:
This brings /usr/share/misc/getopt in sync with the example in getopt(3).
>>> OK, though I wonder if an
>>> Ali H. Fardan 5-Sep-16 09:09 >>>
>
> On 2016-09-05 11:03, Tom Cosgrove wrote:
> :
> > It does allocate the correct buffer size. It's got all the
> > information it needs to do that with the format string and the
> > parameters. Then it returns the buffer address via the `ret'
> > argument.
>
On 09/05/16 10:06, Ali H. Fardan wrote:
> On 2016-09-05 11:04, Otto Moerbeek wrote:
>> On Mon, Sep 05, 2016 at 10:47:06AM +0300, Ali H. Fardan wrote:
>>
>>> On 2016-09-05 10:44, David Gwynne wrote:
> On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
>
> and why is he telling me this? I jus
"Ali H. Fardan" wrote:
>>> Still doesn't mean that it can automagically allocate a correct
>>> buffer size.
>>
>> Yes it does.
>>
>> Arguing about this doesn't help anybody. Go study some C.
>
>You got no explanation for your argument.
No, he doesn't. He owes you nothing. We are not here to
On 2016-09-05 11:03, Tom Cosgrove wrote:
Ali H. Fardan 5-Sep-16 08:47 >>>
On 2016-09-05 10:44, David Gwynne wrote:
>> On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
>>
>> and why is he telling me this? I just said if the destination is a
>> pointer to char, how would a function automagically a
>>> Ali H. Fardan 5-Sep-16 08:47 >>>
>
> On 2016-09-05 10:44, David Gwynne wrote:
> >> On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
> >>
> >> and why is he telling me this? I just said if the destination is a
> >> pointer to char, how would a function automagically allocate a size
> >> for it?
The 3 lines of code it replaced could, so why would you not believe
asprintf() couldn't ?
2016-09-05 9:47 GMT+02:00 Ali H. Fardan :
> On 2016-09-05 10:44, David Gwynne wrote:
>
>> On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
>>>
>>> and why is he telling me this? I just said if the destination
On 2016-09-05 11:04, Otto Moerbeek wrote:
On Mon, Sep 05, 2016 at 10:47:06AM +0300, Ali H. Fardan wrote:
On 2016-09-05 10:44, David Gwynne wrote:
> > On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
> >
> > and why is he telling me this? I just said if the destination is a
> > pointer to char, ho
"Ted Unangst" writes:
> Todd C. Miller wrote:
> > On Sun, 04 Sep 2016 11:58:23 -0600, "Anthony J. Bentley" wrote:
> >
> > > This brings /usr/share/misc/getopt in sync with the example in getopt(3).
> >
> > OK, though I wonder if anyone actually looks at this file?
>
> i think it's better to dele
Sevan Janiyan wrote:
> Hello,
> Attached patches remove the main() prototype from
> src/{sbin,usr.bin,usb.sbin}
yes!
On Mon, Sep 05, 2016 at 10:47:06AM +0300, Ali H. Fardan wrote:
> On 2016-09-05 10:44, David Gwynne wrote:
> > > On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
> > >
> > > and why is he telling me this? I just said if the destination is a
> > > pointer to char, how would a function automagically a
Todd C. Miller wrote:
> On Sun, 04 Sep 2016 11:58:23 -0600, "Anthony J. Bentley" wrote:
>
> > This brings /usr/share/misc/getopt in sync with the example in getopt(3).
>
> OK, though I wonder if anyone actually looks at this file?
i think it's better to delete it.
On 2016-09-05 10:44, David Gwynne wrote:
On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
and why is he telling me this? I just said if the destination is a
pointer to char, how would a function automagically allocate a size
for it?
its not a pointer to a char, its a pointer to a char pointer:
> On 5 Sep 2016, at 17:39, Ali H. Fardan wrote:
>
> and why is he telling me this? I just said if the destination is a
> pointer to char, how would a function automagically allocate a size
> for it?
its not a pointer to a char, its a pointer to a char pointer:
as per the man page:
int
and why is he telling me this? I just said if the destination is a
pointer to char, how would a function automagically allocate a size
for it?
Original Message
Subject: Re: mount(8): strlen + malloc + snprintf == asprintf
Date: 2016-09-05 10:36
From: "Michael W. Bombardieri"
To
Ali H. Fardan wrote:
> If you can read my statement and reply with a proper statement,
> I'd appreciate it.
You are wrong.
On 2016-09-05 08:52, Otto Moerbeek wrote:
On Mon, Sep 05, 2016 at 08:05:40AM +0300, Ali H. Fardan wrote:
On 2016-09-05 08:01, David Gwynne wrote:
> > On 5 Sep 2016, at 12:13, Ali H. Fardan wrote:
> >
> > You can't specify a buffer size in asprintf() therefore, it is not
> > secure,
> > you can
put it in and shine it in the tree?
Index: Makefile
===
RCS file: /cvs/src/share/man/man9/Makefile,v
retrieving revision 1.279
diff -u -p -r1.279 Makefile
--- Makefile2 Sep 2016 17:36:54 - 1.279
+++ Makefile5 Sep 201
48 matches
Mail list logo