The continue statement below is a nop. It seems that it meant to
continue the outer loop. This is an educated guess based on the logic
and the inner loop's comments. Thoughts?
Also, in situations like this, should we make all continue statements
goto loop_end? In the fix I committed for pciide(4)
I've been running -current on a ThinkPad X201 for close to a year now.
iwn times out after about 45-90 seconds every time I boot. This happens
very reliably, regardless of which network I'm connecting to. All I get
to the syslog is:
> Dec 26 17:05:40 thinkpad /bsd: iwn0: timeout waiting for mast
Michal Mazurek wrote:
> Go and Rust are now widely used. It might be worth mentioning them in
> the FAQ.
ok mmcc@
Thanks!
> Index: faq8.html
> ===
> RCS file: /cvs/www/faq/faq8.html,v
> retrieving revision 1.268
> diff -u -p -r1.268
Ricardo Mestre wrote:
> I made an inspection on userland tree and there quite a few
> applications still using strncpy(3) instead of strlcpy(3). Some of
> them may never need that safety since the boundaries are always fixed,
> nevertheless since strlcpy is a drop-in replacement it doesn't hurt to
Christian Heckendorf wrote:
> * Michael McConville [24.12.2015. @16:19:03 -0500]:
>
> > Christian Heckendorf wrote:
> > > A couple of somewhat recent changes in NetBSD's libedit permit
> > > el_gets(3) to accept multibyte characters if the locale supports
>
Christian Heckendorf wrote:
> A couple of somewhat recent changes in NetBSD's libedit permit
> el_gets(3) to accept multibyte characters if the locale supports
> it.
>
> A notable user of this function is sftp(1) which will allow users to
> input multibyte characters, in filenames for example, onc
Michael McConville wrote:
> 1. realloc acts like malloc when ptr == NULL
> 2. no need to check for NULL before free
>
> ok?
I found the same pair in libc. ok?
Index: lib/libc/time/strftime.c
===
RCS file: /cvs/src/l
1. realloc acts like malloc when ptr == NULL
2. no need to check for NULL before free
ok?
? cscope.out
Index: skeleton.c
===
RCS file: /cvs/src/usr.bin/yacc/skeleton.c,v
retrieving revision 1.35
diff -u -p -r1.35 skeleton.c
--- skel
Theo de Raadt wrote:
> I don't know if I am alone in this -- I am getting a bit tired of
> changes which are can be summarized as: "fighting someone else's
> style".
>
> I do not really see the value in changes of this sort.
Agreed. I ordered the includes, but the void casts should just stay.
I'
frit...@alokat.org wrote:
> Hi tech@,
>
> here are some basename(1) tweaks:
> - remove (void) cast for puts(3) and fprintf(3)
We typically leave these. I agree that they're usually pointless visual
distractions in 2015 because there are a set of functions (mostly
blocking IO functions to stdout a
That dmesg got pretty severely mangled by Yahoo. Could you send it
through an email client like Mutt or Thunderbird?
Mark Kettenis wrote:
> > Date: Sat, 12 Dec 2015 16:26:30 -0500
> > From: Michael McConville
> >
> > Mark Kettenis wrote:
> > > It really is confusing to use off_t for something that's not a byte
> > > offset. If integer overflow really i
Mark Kettenis wrote:
> It really is confusing to use off_t for something that's not a byte
> offset. If integer overflow really is an issue you care about, use
> "long long".
ok for the below diff to update my grep change?
> Note that on many non-BSD systems off_t is still a 32-bit integer, at
>
Stefan Sperling wrote:
> On Fri, Dec 11, 2015 at 04:05:49PM -0500, Michael McConville wrote:
> > Bob Beck wrote:
> > > Stability before performance. Tmpfs does not have the former yet.
> >
> > ok mmcc@ for your PR_ZERO diff, as long as there's a comment added
&
Bob Beck wrote:
> Stability before performance. Tmpfs does not have the former yet.
ok mmcc@ for your PR_ZERO diff, as long as there's a comment added about
the performance impact and the potential to back out in the future.
I think it'd still be worthwhile to add the NULL assignment from NetBSD
Bob Beck wrote:
> On Fri, Dec 11, 2015 at 01:09:30AM -0500, Michael McConville wrote:
> > Here's the PR:
> >
> > https://gnats.netbsd.org/50381
> >
> > And the commit:
> >
> > https://marc.info/?l=netbsd-source-changes&m=144694603617544&am
Here's the PR:
https://gnats.netbsd.org/50381
And the commit:
https://marc.info/?l=netbsd-source-changes&m=144694603617544&w=2
We have very few local changes to tmpfs and we share the
KASSERT(de->td_node == NULL), so I think this applies to us.
Thoughts? ok?
Index: sys/tmpfs/tmpfs_subr.c
===
ok?
Index: amd/xutil.c
===
RCS file: /cvs/src/usr.sbin/amd/amd/xutil.c,v
retrieving revision 1.17
diff -u -p -r1.17 xutil.c
--- amd/xutil.c 26 Oct 2014 02:58:43 - 1.17
+++ amd/xutil.c 10 Dec 2015 20:04:43 -
@@ -84,13 +84
>From upstream, reduces diff:
https://github.com/fanf2/unifdef/commit/cf9a7a6f161f3a83c587c485c362fea8d4c0e73e
ok?
Index: unifdef.1
===
RCS file: /cvs/src/usr.bin/unifdef/unifdef.1,v
retrieving revision 1.27
diff -u -p -r1.27 unifd
Objections?
Index: socks.c
===
RCS file: /cvs/src/usr.bin/nc/socks.c,v
retrieving revision 1.22
diff -u -p -r1.22 socks.c
--- socks.c 10 Dec 2015 16:49:28 - 1.22
+++ socks.c 10 Dec 2015 16:52:55 -
@@ -278,7 +278,
Jeff Drago wrote:
> Hello - first post here , hopefully it is the right forum.
>
> I recently setup a bgp box on top of OPENBSD 5.5 Generic.MP, with 6
> INTEL EM nics.The problem is that when I get 700Mbits in one
> interface, the CPU is peaking at 88% (interrupt).
>
> I read about interrupt mod
I thought I'd look for other examples after the grep fix.
ok?
Index: csplit.c
===
RCS file: /cvs/src/usr.bin/csplit/csplit.c,v
retrieving revision 1.8
diff -u -p -r1.8 csplit.c
--- csplit.c11 Oct 2015 17:43:03 - 1.8
+++
Michael McConville wrote:
> Theo de Raadt wrote:
> > Please KNF.
> >
> > case 90:
> > return "Succeeded";
> > case 91:
> >
> > etc.
>
> New diff:
Thoughts, anyone?
> Index: socks.c
> =
Stuart Henderson wrote:
> On 2015/12/08 13:22, Marc Espie wrote:
> > Keep the version, whatever it is.
> >
> > The "check of ports" is annoying, because some of these checks may
> > be in scripts and happen at runtime for ports.
> >
> > The way it usually happens is: something breaks -> porters d
Bob Beck wrote:
> Since I can't think of a sane reason to check this and care in any
> script, yes, kill it.
> ok beck@
Theo pointed out that there may be ports that check the version. I was
considering that too. However, we haven't bumped from 0.9 since 2003.
ggrep is now on 2.22, so I have hope
It's been 0.9 since the original import in 2003...
Index: grep.1
===
RCS file: /cvs/src/usr.bin/grep/grep.1,v
retrieving revision 1.43
diff -u -p -r1.43 grep.1
--- grep.1 13 Jan 2015 04:45:34 - 1.43
+++ grep.1 8 De
No binary change. ok?
Index: cl/cl_main.c
===
RCS file: /cvs/src/usr.bin/vi/cl/cl_main.c,v
retrieving revision 1.27
diff -u -p -r1.27 cl_main.c
--- cl/cl_main.c7 Dec 2015 20:39:19 - 1.27
+++ cl/cl_main.c7 De
It's definitely time for these to go.
The allocation macros would probably be better as functions (e.g.
xmalloc) these days, too. I'll save that diff for another time, though.
No binary change.
ok?
Index: cl/cl_main.c
===
RCS file
Serguey Parkhomovsky wrote:
> Fixes implicit memcpy declarations by using string.h instead of
> strings.h, and removes strings.h from files that don't need it. Also,
> change bzero(3) to memset(3).
This is all committed now. Thanks!
> Index: ask_nbrs2.c
> =
Serguey Parkhomovsky wrote:
> Fixes implicit memcpy declarations by using string.h instead of
> strings.h, and removes strings.h from files that don't need it. Also,
> change bzero(3) to memset(3).
Thanks for this.
I just took care of the existing implicit declarations. Below is a diff
for the re
Otto Moerbeek wrote:
> On Mon, Dec 07, 2015 at 01:36:22AM -0500, Michael McConville wrote:
> > This isn't a grave issue, but I came across it while exploring integer
> > overflow and think it's worth sharing.
> >
> > grep represents line numbers with an int
Michael McConville wrote:
> This isn't a grave issue, but I came across it while exploring integer
> overflow and think it's worth sharing.
>
> grep represents line numbers with an int, which predictably overflows
> for inputs with >= 2^31 newlines. This is easy t
This isn't a grave issue, but I came across it while exploring integer
overflow and think it's worth sharing.
grep represents line numbers with an int, which predictably overflows
for inputs with >= 2^31 newlines. This is easy to demonstrate using the
-n option and a debugging printf.
The below d
Jérémie Courrèges-Anglas wrote:
> Jason McIntyre writes:
>
> > On Sun, Dec 06, 2015 at 04:03:16AM -0500, Ted Unangst wrote:
> >> Jason McIntyre wrote:
> >> > the trouble is i think there are some known bugs with ksh. i
> >> > think it probably would be better to keep a note of them in a
> >> > se
Ted Unangst wrote:
> Jason McIntyre wrote:
> > the trouble is i think there are some known bugs with ksh. i think
> > it probably would be better to keep a note of them in a separate
> > file, as is done now. i'm not really sure if we want to try and
> > clutter the page with every bug we find.
>
Thoughts? ok?
Index: README
===
RCS file: /cvs/src/bin/ksh/README,v
retrieving revision 1.15
diff -u -p -r1.15 README
--- README 5 Dec 2015 19:40:45 - 1.15
+++ README 6 Dec 2015 04:58:27 -
@@ -15,8 +15,3 @@ Fi
Tobias Stoeckmann wrote:
> On Sat, Dec 05, 2015 at 06:26:35AM -0500, Ted Unangst wrote:
> > may i suggest strlen(s) instead of strchr(s, 0)?
>
> There's actually one part in newfs' code that uses this. And in theory
> it has the same issue, not checking if s (which is special, which might
> be arg
Otherwise it warns about memcpy being implicitly declared.
ok?
Index: print-l2tp.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-l2tp.c,v
retrieving revision 1.8
diff -u -p -r1.8 print-l2tp.c
--- print-l2tp.c16 Jan 2015 06:4
Tobias Stoeckmann wrote:
> Opinions, thoughts?
>
> > [...]
> >
> > Index: sbin/newfs/newfs.c
> > ===
> > RCS file: /cvs/src/sbin/newfs/newfs.c,v
> > retrieving revision 1.100
> > diff -u -p -u -p -r1.100 newfs.c
> > --- sbin/newfs/ne
Michael McConville wrote:
> Stuart Henderson wrote:
> > On 2015/12/02 00:04, Michael McConville wrote:
> > > unifdef's -M option is like sed's -i option, editing in-place and
> > > saving a backup with the supplied extension.
> >
> > There is an u
Stuart Henderson wrote:
> On 2015/12/02 00:04, Michael McConville wrote:
> > unifdef's -M option is like sed's -i option, editing in-place and
> > saving a backup with the supplied extension.
>
> There is an upstream for unifdef: http://dotat.at/prog/unifdef/
>
Ricardo Mestre wrote:
> phantasia(6) needs some KNF love, but for now here is a patch to
> ansify it:
Did you verify that there's no binary change?
> Index: fight.c
> ===
> RCS file: /cvs/src/games/phantasia/fight.c,v
> retrieving re
unifdef's -M option is like sed's -i option, editing in-place and saving
a backup with the supplied extension.
Currently, if -M '' is passed:
* the original file is copied to the backup filename (i.e. itself)
* the temp file is copied to the original filename
It therefore has the same behavio
Theo de Raadt wrote:
> Please KNF.
>
> case 90:
> return "Succeeded";
> case 91:
>
> etc.
New diff:
Index: socks.c
===
RCS file: /cvs/src/usr.bin/nc/socks.c,v
retrieving revision 1.21
diff -u -p -r1.21 so
When an nc SOCKS connection fails, you get an error message like this:
> connection failed, SOCKS error 6
Obviously, this would be clearer with error strings.
ok?
Index: socks.c
===
RCS file: /cvs/src/usr.bin/nc/socks.c,v
retrievi
1. A clearer wording of allocation failure
2. ksh has job control and is the default shell
ok?
Index: lib/libc/string/strdup.3
===
RCS file: /cvs/src/lib/libc/string/strdup.3,v
retrieving revision 1.21
diff -u -p -r1.21 strdup.3
Serguey Parkhomovsky wrote:
> On Thu, Nov 26, 2015 at 01:03:22PM -0500, Michael McConville wrote:
> > This nondeterministically underflows _sf_top_ix, causing a segfault:
> >
> > http://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/crash.l
> >
>
> Looks
Theo de Raadt wrote:
> > > If it is not our own fork -- then stay away from this. It is
> > > pointless putting increasing delta into code which does not run in
> > > risk environments.
> >
> > I thought we had already made that decision based on tedu's recent
> > commits. Not sure though.
>
> I
Theo de Raadt wrote:
> We need to make a decision if lex is upstream code or our own fork.
>
> If it is not our own fork -- then stay away from this. It is
> pointless putting increasing delta into code which does not run in
> risk environments.
I thought we had already made that decision based
The second reallocarray is unnecessary, but it'll prevent the next forty
auditors from being distracted by malloc(x * sizeof(y)). I'm happy to
leave malloc if people prefer that.
ok?
Index: scanflags.c
===
RCS file: /cvs/src/usr.bin
This nondeterministically underflows _sf_top_ix, causing a segfault:
http://www.sccs.swarthmore.edu/users/16/mmcconv1/dump/crash.l
The cleanest way to trigger it is:
for i in `jot 1000`
do
cat crash.l | ./lex -t > /dev/null
done
A backtrace is below.
sf_pop() is the only code t
Ricardo Mestre wrote:
> While checking if there was still a score file on trek(6) I found that
> it was still using random(), and inspired by the code on NetBSD and
> OpenBSD relevant manpages I came up with this diff. Let's bring
> trek(6) to the 21st century, at least here :) Does it look good?
Larry Hynes wrote:
> PC's is a possessive form, PCs a plural one: The plural of peecee is
> peecees, not peecee's.
Committed. Thanks.
> Index: i386.html
> ===
> RCS file: /cvs/www/i386.html,v
> retrieving revision 1.735
> diff -r1.73
Bühler Theo wrote:
> > It seems apparent that they never go negative. All instances are used to
> > manipulate strlen() values.
> >
> > ok?
>
> the first hunk is fine with me. I don't understand the second one:
> why only convert w? Aren't all three ints guaranteed to be unsigned there?
The shor
It seems apparent that they never go negative. All instances are used to
manipulate strlen() values.
ok?
Index: c_ksh.c
===
RCS file: /cvs/src/bin/ksh/c_ksh.c,v
retrieving revision 1.46
diff -u -p -r1.46 c_ksh.c
--- c_ksh.c 21 O
I agree that this is very cool. It's probably also worth mentioning that
there's a long discussion on NetBSD's tech-kernel@ right now about a
WABPL-related panic. Not sure whether that's relevant to this diff.
I'm already cache-thrashing with all of my side projects, so if anyone's
interested I'll leave this to them.
A few days ago, I wanted to try American Fuzzy Lop (afl), and bc(1)
seemed like a good first target: it pretty much just goes from stdin to
stdout, so there's no code reorganization needed.
Ted Unangst wrote:
> Joerg Jung wrote:
> > > Michael McConville wrote:
> > > Relayd, httpd, and ntpd define the functions get_data() and
> > > get_string(). Both call calloc and then immediately memcpy.
> > > Calloc's zeroing isn't optimized out.
Ted Unangst wrote:
> memory.h is spelled string.h now.
ok?
Index: etherent.c
===
RCS file: /cvs/src/lib/libpcap/etherent.c,v
retrieving revision 1.7
diff -u -p -r1.7 etherent.c
--- etherent.c 27 Jan 2004 06:58:03 - 1.7
+++
Ted Unangst wrote:
> Theo Buehler wrote:
> > drop the score file support
>
> No way! this is critical functionality. :)
Seconded. :P
ok?
Index: pax.h
===
RCS file: /cvs/src/bin/pax/pax.h,v
retrieving revision 1.27
diff -u -p -r1.27 pax.h
--- pax.h 19 Mar 2015 05:14:24 - 1.27
+++ pax.h 16 Nov 2015 18:23:24 -
@@ -79,7 +79,7 @@ typedef struct
Jan Stary wrote:
> When we set perf policy to high, we say "high".
> So when we set to low, say "low", not "manual".
> (Both manual high and manual low are manual.)
>
> And it's not "client reply", it's a reply to the client, right?
ok mmcc@
> Index: apmd.c
>
I may be missing something obvious here, but it seems that the below
indices should be unsigned. str_table has UCHAR_MAX elements, so it
expects to be indexed by chars > 127.
I'm currently digging through a bunch of segfaults found by American
Fuzzy Lop (afl). I don't think I've come across this i
Craig Rodrigues wrote:
> Recently, I imported imsg.c from OpenBSD to the
> FreeBSD base system's libopenbsd:
>
> https://svnweb.freebsd.org/changeset/base/290375
>
> When compiling on FreeBSD, we get a compiler warning with clang:
>
> cc -O2 -pipe -I/opt2/branches/head2/lib/libopenbsd -std=gn
Alexandre Ratchov wrote:
> On Thu, Nov 12, 2015 at 02:52:01PM +0800, Michael W. Bombardieri wrote:
> > > > ok for removing xfree from aucat?
> > >
> > > yes, ok ratchov; if later this causes me merges i'll find another
> > > solution. Feel free to do the same in usr.bin/sndiod, as it's
> > > almo
Ricardo Mestre wrote:
> It seems I was still with mangling problems, does it look good now?
You're still wrapping a couple lines in the second-to-last hunk, but I
fixed them manually.
ok mmcc@
> Index: alloc.c
> ===
> RCS file: /cvs
Ricardo Mestre wrote:
> Hi,
>
> On csh(1), since Free() just calls free() and xfree() is a #define to
> Free() then free() can be called directly instead of xfree() and the
> #define can be removed, is this approach correct?
Seems like this patch is mangled, unless it's something on my machine.
Michael W. Bombardieri wrote:
> > > ok for removing xfree from aucat?
> >
> > yes, ok ratchov; if later this causes me merges i'll find another
> > solution. Feel free to do the same in usr.bin/sndiod, as it's
> > almost the same.
>
> Same thing for sndiod...
ok mmcc@
> Index: abuf.c
> ===
That helper function I just tweaked has a total of one usage. Maybe just
inline it?
Index: opttbl.c
===
RCS file: /cvs/src/usr.bin/less/opttbl.c,v
retrieving revision 1.16
diff -u -p -r1.16 opttbl.c
--- opttbl.c12 Nov 2015 03:13:
is_optchar() could also take an int in order to be more compatible with
the ctype functions.
isupper() || islower() is equivalent to isalpha() in the C locale, but
not necessarily in others (see the isalpha(3) manpage).
We could use stdbool to make is_optchar() a one-liner, but I'll resist
the te
Michael W. Bombardieri wrote:
> Hi tech@,
>
> In dc(1) the function array_free() knows how to skip a null pointer so
> calling code doesn't need to avoid passing null.
> Also, minor style (braces) clean-up.
ok mmcc@
It may also be a good idea to change the allocation names in the form
bmalloc ->
Manuel Giraud wrote:
> Hi,
>
> Here is a typo in the verbose mode of restore:
ok mmcc@
> Index: tape.c
> ===
> RCS file: /cvs/src/sbin/restore/tape.c,v
> retrieving revision 1.46
> diff -u -p -r1.46 tape.c
> --- tape.c25 Aug 201
Here, I:
1) remove a useless comment
2) remove a needless void* cast
3) remove a bunch of NULL-checks for free()
4) simplify a little associated logic
Call me a one trick pony.
ok?
Index: cmdbuf.c
===
RCS file: /cvs/src/usr.b
Michael McConville wrote:
> Maybe we should pick this off in smaller chunks so that we don't get
> immobilized by a few scattered issues.
>
> ok for removing xfree from aucat?
I just realized that this one was already submitted separately.
Tobias, could you split your latest d
Maybe we should pick this off in smaller chunks so that we don't get
immobilized by a few scattered issues.
ok for removing xfree from aucat?
Index: abuf.c
===
RCS file: /cvs/src/usr.bin/aucat/abuf.c,v
retrieving revision 1.26
diff
Benjamin Baier wrote:
> Hello tech@
>
> I cleaned up and split up my former diff[0] for removing superfluous
> case '?': /*FALLTHROUGH*/
> default:
> usage();
>
> Also removes one unnecessary break;
>
> This is for /sbin, more to come if there are any takers?
> Greeting
Alexandre Ratchov wrote:
> On Sun, Nov 08, 2015 at 09:56:23AM +0800, Michael W. Bombardieri wrote:
> > On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote:
> > > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote:
> > > > I don't know why cvs and rcs xmalloc.c has ended
Michael W. Bombardieri wrote:
> On Thu, Nov 05, 2015 at 03:50:29PM +0100, Tobias Stoeckmann wrote:
> > On Thu, Nov 05, 2015 at 09:50:48AM +, Nicholas Marriott wrote:
> > > I don't know why cvs and rcs xmalloc.c has ended up so different.
> >
> > It's not just about cvs and rcs:
> >
> > /usr/s
Nicholas Marriott wrote:
> Looks good, ok nicm
Reviewing now, generally looks good.
A few things:
I don't understand the motive for all the err() -> errx() and fatal() ->
fatalx() changes. If I came across these, I probably would have
suggested the reverse. err(1, "xstrdup") is a lot cleaner tha
Ted Unangst wrote:
> less has a peculiar estrdup function. unlike ecalloc etc., it only
> prints an error but doesn't quit. But the callers don't seem to check
> for null. And in many places they call a function called save()
> instead.
>
> It is clearer to make estrdup() quit and use it everywher
Apparently the programmer didn't know that you could pass it NULL.
However, including the function name seems more informative.
ok?
Index: usr.sbin/netgroup_mkdb/util.c
===
RCS file: /cvs/src/usr.sbin/netgroup_mkdb/util.c,v
retrievi
Michael McConville wrote:
> > It's not documented so it doesn't exist for me. :P
> >
> > (hint hint)
>
> Seconded.
I thought thought that this was referring to the undocumented top
option. Disregard. :)
Marc Espie wrote:
> On Thu, Nov 05, 2015 at 11:52:32AM +0100, Theo Buehler wrote:
> > On Thu, Nov 05, 2015 at 11:33:56AM +0100, Marc Espie wrote:
> > > On Thu, Nov 05, 2015 at 10:54:32AM +0100, Theo Buehler wrote:
> > > > On Thu, Nov 05, 2015 at 10:42:54AM +0100, Marc Espie wrote:
> > > > > - i
Ted Unangst wrote:
> Michael McConville wrote:
> > It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's
> > almost exclusively used for uvm_map()'s flag arg, which has that type.
> > Of course, it's an arithmetic macro, so it doesn't
Michael W. Bombardieri wrote:
> Hi tech@,
>
> Function xfree() was previously removed from rcs, so drop it from
> opencvs too...
>
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/rcs/xmalloc.c?f=h#rev1.9
Good catch, thanks.
My eyes glazed over a little while reviewing this, but tentative
It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's
almost exclusively used for uvm_map()'s flag arg, which has that type.
Of course, it's an arithmetic macro, so it doesn't actually have a
return type.
ok?
Index: share/man/man9/uvm.9
=
Ruslan Babayev wrote:
> This fixes the portable LibreSSL build on Linux with GCC5 for MIPS64.
Is __GNUC_PREREQ__ from /usr/include/sys/cdefs.h in other OSs? If not,
you could probably just add it to the LibreSSL portability headers. It's
probably the easiest and most readable solution if these sor
sanitization. So, maybe we should only change it
in performance-relevant areas where we're very confident in the safety
of the program logic.
> On Mon, Nov 02, 2015 at 12:31:14PM -0500, Michael McConville wrote:
> > Don't bother mallocing a statically-sized 1,024-byte chunk o
Don't bother mallocing a statically-sized 1,024-byte chunk of mem, for
simplicity and speed.
ok?
Index: usr.bin/cvs/server.c
===
RCS file: /cvs/src/usr.bin/cvs/server.c,v
retrieving revision 1.102
diff -u -p -r1.102 server.c
--- usr
ok?
Index: usr.bin/uniq/uniq.c
===
RCS file: /cvs/src/usr.bin/uniq/uniq.c,v
retrieving revision 1.22
diff -u -p -r1.22 uniq.c
--- usr.bin/uniq/uniq.c 9 Oct 2015 01:37:09 - 1.22
+++ usr.bin/uniq/uniq.c 2 Nov 2015 17:17:13 -0
ok?
Index: usr.bin/whois/whois.c
===
RCS file: /cvs/src/usr.bin/whois/whois.c,v
retrieving revision 1.50
diff -u -p -r1.50 whois.c
--- usr.bin/whois/whois.c 9 Oct 2015 01:37:09 - 1.50
+++ usr.bin/whois/whois.c 2
Todd C. Miller wrote:
> On Mon, 02 Nov 2015 09:16:07 +, Nicholas Marriott wrote:
> > I looked briefly at this and it wouldn't be that hard. However,
> > while it would be fantastic to clean up all the crap from less, it
> > isn't clear if Garrett D'Amore is going to be keeping his fork up to
>
Michael McConville wrote:
> Diff below. Is anyone running an NFS server on -current willing to
> test?
Disregard, this needs more initial testing (by me) first. It's hanging
when registering the service.
> I
The two most recent diffs here:
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/mountd/mountd.c?only_with_tag=MAIN
Here's the referenced PR:
https://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=48282
Essentially, we daemonize after rather than before registering the
serv
Every one of these is in a var declaration, so a megadiff is probably
the easiest way to do it.
ok?
Index: brac.c
===
RCS file: /cvs/src/usr.bin/less/brac.c,v
retrieving revision 1.6
diff -u -p -r1.6 brac.c
--- brac.c 25 Apr 20
Michael McConville wrote:
> Mike Burns wrote:
> > On 2015-11-01 10.44.45 -0500, Michael McConville wrote:
> > > Index: history.c
> > > ===
> > > RCS file: /cvs/src/bin/ksh/history.c,v
> > &
1. I don't see much reason to mention calloc() as an alternative to
reallocarray() when it's the worse option.
2. Use size > 0 when testing overflow.
ok?
Index: lib/libc/stdlib/malloc.3
===
RCS file: /cvs/src/lib/libc/stdlib/malloc
Mike Burns wrote:
> On 2015-11-01 10.44.45 -0500, Michael McConville wrote:
> > Index: history.c
> > ===
> > RCS file: /cvs/src/bin/ksh/history.c,v
> > retrieving revision 1.52
> > diff -u -p -r1.52 hi
ok?
Index: history.c
===
RCS file: /cvs/src/bin/ksh/history.c,v
retrieving revision 1.52
diff -u -p -r1.52 history.c
--- history.c 1 Nov 2015 15:38:53 - 1.52
+++ history.c 1 Nov 2015 15:44:02 -
@@ -507,7 +507,7 @@ s
Serguey Parkhomovsky wrote:
> Is there any interest in having a newer version of flex in base? I
> recently tried compiling some software with OpenBSD's flex, but had to
> tweak some code in order to get it to compile with 2.5.4. Of course, I
> could always install the flex in ports to get a newer
101 - 200 of 313 matches
Mail list logo