Thomas Klausner | 26 Nov 00:38 2014

patch core dump with line number overflow


Also seems to apply to NetBSD's patch(1).

Kamil Rytarowski | 25 Nov 00:22 2014

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


OpenBSD standardized in its eco-system i.e. two functions:
- reallocarray(3) is a safer drop-in replacement of realloc(3)
- strtonum(3) is yet another function to change literal string to a number

strtonum(3) became a BSD standard (OpenBSD since 3.6 A.D. 2004, FreeBSD since 6.1 A.D. 2004)
reallocarray(3) was introduced in OpenBSD 5.6 (A.D. 2014)

I don't want to start rant how these functions are good or needed, my personal intention is different:
easier code share between our BSD systems. To narrow things down, I want to use an unmodified piece of code
from the OpenBSD sources - and there pops out this compat problem.

I can see 4 solutions:
- push things upstream and import strtonum(3) and reallocarray(3) to NetBSD's stdlib,
- wrap around a system-wide reusable source-code level OpenBSD compat layer,
- patch Linux specific libbsd for emulation of OpenBSD in the NetBSD environment (I really don't want to do this!),
- all-time patching sources for missing functions and it's not so unmodified anymore (I'm so bored of
losing my time on this...).

In reality all current code in OpenBSD reuses these two functions (not counting a few bit more specialized
like explicit_bzero(3)).

If we will ever collaborate with OpenBSD with e.g. LibreSSL (not tracking how it is with at least mandoc)
these functions are must. The first solution opens possibility to reuse these functions in our
eco-system as well, the second one gives me possibility to stop making compat functions anymore for other too.

I'm a volunteer for a public-report with a patch.

Manual pages as references:
(Continue reading)

Rocky Hotas | 24 Nov 11:04 2014

Re: Understanding a source code file

Thank you for all your useful advices.
As a real "technical" clarification, there are two versions of "banner" in the system, one in /usr/games
and one in /usr/bin/banner.
The source code we used was that of /usr/games/banner. But this is not the program runned after typing
"banner" in the system, which by default is located in /usr/bin/banner. It is different and it has a
different output. Its source code is located instead in

I will test them following your useful hints.


> Sent: Saturday, November 22, 2014 at 12:28 AM
> From: "Iain Hibbert" <plunky <at>>
> To: "Rocky Hotas" <rockyhotas <at>>
> Cc: "tech-userlevel <at>" <tech-userlevel <at>>
> Subject: Re: Understanding a source code file
> On Fri, 21 Nov 2014, Rocky Hotas wrote:
> > Hoping this is the right section for my question.
> maybe, in that it is a technical question relating to a userland program..
> however, I think you are asking a basic programming question really
> > I would like to correctly understand the contents of a simple source
> > file: it is banner.c (/src/games/banner), the version contained in
(Continue reading)

Ted Unangst | 24 Nov 01:48 2014

fix for base64.c "overrun"

>From inspection, it appears that base64.c in libc will erroneously
detect a pending overflow when pton decodes a base64 string into a
precisely sized buffer. The same bug existed in OpenBSD; it would be
nice if it were fixed in NetBSD as well.

Rocky Hotas | 21 Nov 22:19 2014

Understanding a source code file

Hoping this is the right section for my question. I would like to correctly understand the contents of a
simple source file: it is banner.c (/src/games/banner), the version contained in

It is the source code of a very simple program, as you know.
In the first lines, there are two "static const int" arrays declared: it seems to be a mapping. I can't also
understand the format of the "Table of stuff to print" between the two arrays.
First of all, what does this part mean?
I have never analyzed a NetBSD kernel or something similar. Supposing that I know the basics of the C
language, is there a standard way to proceed in the analysis of such source files? (I didn't find useful
sites talking about this topic)
Thank you,


Emile `iMil' Heitor | 20 Nov 09:51 2014

mount_vnd ? patch included


At ${DAYJOB} we commonly use raw disk images in order to speed up accesses on
NFS large volumes. Under linux, this is achieved by mounting the image as a
loopback device and can be done directly at boot time using the fstab(5): /data auto _netdev,noatime,async,loop 0 0

Under NetBSD, we can mount such images using vnconfig(8) and mount(8) but it
can't be done directly from the fstab, or at least I haven't found how. This
small script does the job as long as it is called `mount_vnd' and is placed in
`/sbin' or `/usr/sbin' as shown in `src/sbin/mount/mount.c':

$ cat /sbin/mount_vnd 

while [ $# -gt 0 ]; do
         case ${1} in
                 [ "${2}" = "noauto" ] && exit 0
                 [ "${2}" = "ro" ] && vnopt="-r"
(Continue reading)

Aymeric Vincent | 11 Nov 12:25 2014

compiler_rt missing support for 80-bit floats?


while trying to compile libuhd on NetBSD, I stumbled upon an undefined
reference to __trunctfxf2 at link time of the first example program.

This function truncates a 128bit float to 80 bits. Digging around, I
found out that we have three implementations of the softfloat emulation
in the tree. The one given with gcc is not used.

This leaves us with src/lib/libc/softfloat which seems to lack the alias
required for this function. I enclose a patch which adds it there but I
don't know if it's still used on any platform, probably depends on the
gcc version being used. It's clearly not used on amd64, even on the
netbsd-7 branch.

So, the implementation we currently use is provided by compiler_rt in
src/sys/external/bsd/compiler_rt/dist/lib/builtins but also lacks the
implementation of this function.

Could someone with experience on floating point and/or compiler_rt
please tell if it's a simple matter of adding the 80-bit case to and add stub C files, or if there is a deeper reason
for dropping 80bit support?


(the following patch is for reference only if someone else is interested
 for another platform/gcc combination, I couldn't test it)
(Continue reading)

Aymeric Vincent | 11 Nov 12:00 2014

login(1) vs "dialout ttys"


while looking at usr.bin/login/login.c, I noticed the following strange

	if (tty[sizeof("tty")-1] == 'd')
		syslog(LOG_INFO, "DIALUP %s, %s", tty, pwd->pw_name);

The intent seems obvious (if the name contains a 'd' in a position which
would agree with "ttyd", syslog that we have a dialup login) but it
seems to be a sloppy test which is furthermore incoherent with the
current naming of our devices.  (It can't currently lead to an out of
bounds access because ttyname(3) returns a static PATH_MAX-length array)

After a quick look around, ttys(5) mentions ttyd0 as a dialout device in
its examples section, and the MAKEDEV.conf of the vax seems to avoid
ttyd in its enumeration of ttys, but on the other hand quite a handful
of ports use tty[a-d] as usual serial ports and logins on ttyd would
spam syslog uselessly.

Out of curiosity, I'm also interested to know if /dev/dtyxx is the new
incarnation of /dev/ttydxx or if they serve different purposes.

Also, checking with cvs annotate dug up a very old PR which induced the
removal of the test but the test was added back a few months later as a
merge of 4.4lite.

(Continue reading)

Masao Uebayashi | 7 Nov 05:15 2014

Macro to define absolute symbol

I want to define absolute symbols in ELF files, using as(1) '.equiv' directive,
as done in _KERNEL_OPT_* symbols in kernel build.  Could anyone look and
complete this, including the !__STDC__ part and cdefs_aout.h?

My use-case is to define COHERENCY_UNIT for linker script.

Index: sys/sys/cdefs_elf.h
RCS file: /cvsroot/src/sys/sys/cdefs_elf.h,v
retrieving revision 1.46
diff -p -u -r1.46 cdefs_elf.h
--- sys/sys/cdefs_elf.h	26 Aug 2014 09:03:17 -0000	1.46
+++ sys/sys/cdefs_elf.h	7 Nov 2014 04:06:50 -0000
 <at>  <at>  -130,6 +130,16  <at>  <at> 

+#if __STDC__
+#define	__SYMVAL(sym, val)						\
+	__asm(".globl	" #sym);					\
+	__asm(".equiv	" #sym ", " __STRING(val))
+#define	__SYMVAL(sym, val)						\
+	__asm(".globl	sym");						\
+	__asm(".equiv	sym, " __STRING(val))
 #define	__IDSTRING(_n,_s)		__SECTIONSTRING(.ident,_s)

 #define	__RCSID(_s)			__IDSTRING(rcsid,_s)
(Continue reading)

Marc Balmer | 14 Oct 08:33 2014

Binary packages on NetBSD: Importing pkg(8) from FreeBSD?

[This has also been posted to pkgsrc-users <at>]

FreeBSD has now by default pkg(8) (formerly called pkgng) as the default manager for _binary_ packages.  It
replaces the old pkg_* tools.  pkg(8) is a manager for binary packages _only_; to produce the binary
packages the FreeBSD ports system is used almost unaltered.  pkg(8) has been designed to be a modern binary
package manager that can among other things properly deal with update situations, properly resolve
dependencies and in general allows systems to be managed with binary packages easily.

pkg(8) is not part of the base system, the base system only contains a way to bootstrap pkg(8).  pkg(8) itself
resides in the FreeBSD ports tree.

I think pkg(8) would be a good thing for NetBSD to have, too.  pkg(8) is properly designed and allows for
different binary package formats (at least in theory), so it could probably be feasible to add a pkg(8)
backend that handles binary packages produced using pkgsrc.

afaict, the following steps would be needed:

- Tell the upstream developers about our plans (the pkgsrc backend should become part of the upstream code,
if possible)
- Import the pkg(8) bootstrap mechanism into NetBSD base (src/external).
- Extend pkg(8) to deal with pkgsrc-produced binary packages.
- Import pkg(8) into pkgsrc.
- Coordinate local changes with the upstream developers.

As pkg(8) "only" deals with binary packages, this would be complimentary to the existing pkg_* tools that
come with pkgsrc, i.e. it's use would be optional.

Is anyone besides me interested in such work and would be able/willing to spend some amount of time on this?

- mbalmer
(Continue reading)

Edward Tomasz Napierała | 30 Sep 13:19 2014

Re: FreeBSD got a new automounter

Just FYI, I'll happily help you with porting the automounter.  Userland
part should be trivial; I don't think it contains any system-specific
code, apart from autofs ioctls.  The kernel part is not complicated either,
but will need someone who knows NetBSD VFS.