David Holland | 15 Feb 21:42 2015

remove vgrind?

So... vgrind(1) seems to have basically nothing going for it. Its
purpose is to typeset source with syntax highlighting; but its syntax
highlighting is extremely primitive. For example, the very basic
syntax highlighting in print/enscript produces much better output.

Meanwhile, most of its options don't work; it handles most of them by
issuing options to groff that are not groff options (perhaps they were
original-troff options once upon a time). This includes the option to
avoid shipping the output to $PRINTER for you.

The code is a legacy pile (vgrind itself is a csh script) and it has
no structure and no notion of output backends, so it's limited to
troff output only. Also it has its own regexp implementation for
processing the input to highlight it, and this regexp implementation
for some reason has nonstandard semantics. Finally, while the
highlighting is somewhat configurable, the config file is a
termcap-style file, which is only slightly less human-readable than

All of this could be fixed, but it would take a total rewrite and I'm
not convinced there's any point; it would be better to just delete it,
or if we can't make up our minds to that, at least throw this code out
and start over.

There is one thing it can do that isn't readily available off the
shelf otherwise, and that's process code embedded in roff source.
Does anyone care about this in their own documents? There are four
uses in the tree in /usr/share/doc/papers, but none of these would
lose anything by being turned into vanilla literal blocks.

(Continue reading)

Kamil Rytarowski | 7 Feb 16:41 2015

<overflow.h> request for review


I'm attaching a proposition of an overflow library,
as a part of the NetBSD kernel and libc with dedicated
header overflow.h.

The library was inspired by libo by Xi Wang:

Xi Wang was kind to license his work to BSD.
I keep his license note as a credit even though
in the final work there is little code share.

The library was designed as a fast overflow checking
utilities, however in the final work I put the emphasis
on the safety rather then speed. A good compiler like
GCC/Clang will likely optimize the code for efficiency
on an architecture that is capable of it (like i386).

The library is intended to be used as a layer in libc
and kernel, everywhere an integer operation may overflow
in the * / + - operations.

if (overflow_mul(&c, a, b))

The library is type agnostic, and for this there is need
for a C11 or GCC-compatible compiler. At the moment PCC
isn't supported.
(Continue reading)

Kamil Rytarowski | 7 Feb 20:10 2015

Disable texinfo by default?


The GNU tool-chain ships with a documentation in the info
format. info is kind of a predecessor of html, something
between man(1) and www resources.

./build.sh ships with the MKINFO swap
Can be set to ``yes'' or ``no''.  Indicates whether GNU Info
files, used for the documentation for most of the compilation
tools, will be created and installed during a build.

Default: ``yes''

Nowadays info is mostly replaced by quality man (with an
option of htmlized man-pages with working links and styles)
and by web resources sensu largo. There are discussions in
the core GNU poject Emacs about migration from info to
something else, with (according to ESR) approval from RMS.


My proposition is to turn MKINFO by default to no for NetBSD 8+.

Any comments?

Joerg Sonnenberger | 5 Feb 20:40 2015


Hi all,
as discussed in the recent strtonum thread, I believe that reallocarray
is wrong in the way it makes error handling more complicated to get
right. Attached is an alternative, including modifications for regcomp.c
for an IMO better interface. There is one issue with reallocarr(3) and
that's related to the C type system. Sadly, void ** and foo ** are not
implicit cast compatible, that's why the prototype takes a void *

Attachment (reallocarr.diff): text/x-diff, 13 KiB
Andrei M. | 3 Feb 21:39 2015

NetBSD volunteering (WiFi browser, NPF Web UI)

Hello everybody,

I've been using NetBSD on and off for 12 years now (whenever I take a
break from Linux) and thought may be it was about time to do some
volunteer work for the project. Even though I'm not directly a
professional programmer, I've got some scientific background and
programming is far from being strange to me (as you might expect from
someone using NetBSD).

But I simply don't know where to begin. I've had a look at the list of
NetBSD projects at the official website and picked up two that caught
my interest (as those were something I had already thought about on my

1. WiFi browser
Create an easy to use wifi setup widget for NetBSD: browse and select
networks in the vicinity by SSID, BSSID, channel, etc.

2. Web UI for NPF
NPF is a packet filter for the NetBSD system. The goal of this project
is to create a web-based user interface for NetBSD + NPF as a firewall

This mailing list was mentioned for reference, so I'm writing here. In
case either project is unfinished, I could assist with developing,
testing and other helpful things in my free time. If these projects
are closed I'm open to any good advice on which other project I could
contribute to instead (you can also mail me off the list).
(Continue reading)

Kamil Rytarowski | 3 Feb 01:48 2015

(patch) new test: t_strtoi


I'm attaching a new test for strtoi(3).
A test for strtou(3) will be next.

Attachment (patch-distrib): application/octet-stream, 2167 bytes
Attachment (patch-etc): application/octet-stream, 887 bytes
Attachment (patch-tests): application/octet-stream, 9 KiB
Kamil Rytarowski | 31 Jan 03:59 2015

Cleanup of utilities, upgrade to C99?


I was going to reuse new strtoi(3) API in our own code (mostly /(usr/)(s)bin)
in places where atoi(3) and strtol(3) could be happily replaced with benefit.

I was looking at the code of our utilities and few things are unclear to me.
We are struggling for portability of the code, but does it mean that we are
struggling for being a portable code donor?

By portable code donor I mean to use the oldest possible C (pre-)standard
with code variations for e.g. freebsd that was old already in 1996 and
I can't see the bug in the mentioned libc function in FreeBSD's SVN
in the initial revision from 1994 (what was their code before that?)
(memchr(3) usage note in strip_nuls() from ksh/misc.c).

I see a point of bootstrapping (to build the toolchain with build.sh)
in an environment where NO_REALLOC_NULL (example from ed(1)) may be defined,
but I'm unsure whether it's the policy to preserve the compatiblity in
utilities like ed(1)?

Another example from the Korn Shell:
ksh(1) is written in K&R, but the patches merged in NetBSD are in C99

The original imported code had these lines (till now unchanged):

# include <limits.h>
(Continue reading)

Kamil Rytarowski | 31 Jan 02:34 2015

patch cat(1) improve -B


cat(1) says:
-B bsize
Read with a buffer size of bsize bytes, instead of the default
buffer size which is the blocksize of the output file.

I'm attaching a small patch:
- documenting -B0 as back-ward compatible behavior,
- handling invalid number parameter.

$ cat -Baaa

$ ./a.out -Baaa
a.out: Invalid buffer size 'aaa': Operation Canceled

Attachment (patch-cat): application/octet-stream, 1278 bytes
Christos Zoulas | 13 Jan 14:18 2015

Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD

On Jan 13,  3:43am, n54 <at> gmx.com ("Kamil Rytarowski") wrote:
-- Subject: Re: Reuse strtonum(3) and reallocarray(3) from OpenBSD

| Hello,
| I've divided the work to parts:
| 1. add strtoi, strtou, fullstrtoi. fullstrtou

I still don't get what you buy by having 2 sets of functions to save a passed
NULL pointer... Aside confusion.

| 2. add efuns
| 3. add manpages
| 4. add strtonum(3) as _OPENBSD_SOURCE

I am fine with the rest, I don't see a need for the full* and I have not
looked at the patch portion since it was uu'ed and I was too lazy to unpack.

| +
| +	if (rerror == NULL)
| +		rerror = &rep;
| +
| +#if defined(_KERNEL) || defined(_STANDALONE) || \
| +    defined(HAVE_NBTOOL_CONFIG_H) || defined(BCS_ONLY)
| +	im = __WRAPPED(ptr, &ep, base, lo, hi, rerror);
| +#else
| +	im = __WRAPPED_L(ptr, &ep, base, lo, hi, rerror, loc);
| +#endif
| +
| +	if (ptr == '\0' || *ep != '\0') {
(Continue reading)

Jeremy C. Reed | 12 Jan 16:23 2015

syslog message with wrong date, and patch for newsyslog

My syslog had been dead for a few days. (I saw some cronjob mail about 
newsyslog unable to kill.)

Today I looked at some logs and saw no updates for a week. So I saw 
syslogd not running. I started it and immediately logged:

Jan 12 09:08:29 t1 syslogd[17678]: restart
Jan 12 09:08:29 t1 /netbsd: UVM: pid 4690 (vi), uid 1000 killed: out of 
Jan 12 09:08:29 t1 /netbsd: UVM: pid 156 (syslogd), uid 0 killed: out of 

(I know this vi crash was due to editing with vi -r. I am pretty sure 
this is fixed now but cannot find the gnats ticket number.)

So the last two messages with today's timestamps really happened maybe 
on January 6.

By the way, a couple days ago I updated my newsyslog with:

Index: newsyslog.c
RCS file: /cvsroot/src/usr.bin/newsyslog/newsyslog.c,v
retrieving revision 1.61
diff -u -r1.61 newsyslog.c
--- newsyslog.c	5 Sep 2013 11:34:40 -0000	1.61
+++ newsyslog.c	12 Jan 2015 15:12:25 -0000
 <at>  <at>  -623,7 +623,9  <at>  <at> 
 			    sys_signame[log->signum], (u_long)pid));
 			if (!noaction)
(Continue reading)

Patrick Welche | 6 Jan 12:14 2015


gcc 4.8 seems less confused about "action" being used uninitialised after
application of attached patch. Makes sense?


Index: pkill.c
RCS file: /cvsroot/src/usr.bin/pkill/pkill.c,v
retrieving revision 1.29
diff -u -r1.29 pkill.c
--- pkill.c	2 Jan 2013 10:36:07 -0000	1.29
+++ pkill.c	6 Jan 2015 11:12:22 -0000
 <at>  <at>  -128,8 +128,8  <at>  <at> 
 		action = grepact;
 		pgrep = 1;
 	} else if (strcmp(getprogname(), "prenice") == 0) {
+		action = reniceact;
 		prenice = 1;
 	} else {
 		action = killact;
 		p = argv[1];
 <at>  <at>  -171,7 +171,6  <at>  <at> 
 		if (argc < 2)

-		action = reniceact;
(Continue reading)