William Orr | 23 May 17:51 2015

libintl updates


Here is some of my initial work on updating libintl. The first two patches are
small updates that remove some extraneous NULL checks. The third adds the
gettext functions that take a context argument to libintl, as detailed in

Let me know what I need to fix up.

William Orr

Pierre Pronchery | 21 May 12:30 2015

Buffering in standard streams

		Hi tech-userlevel <at> ,

I just read this nice article from a coreutils maintainer:

After detailing issues about buffering and pipes, it mentions a tool,
stdbuf(1), which was introduced in coreutils and then imported to
FreeBSD (since 8.4).

Do we want this too?



William Orr | 19 May 08:42 2015

libintl updates


I've started working on an update to libintl. Currently, I've 
implemented the new functions/macros that were added in GNU gettext that 
take a context argument as described: 

As far as I can tell from the NEWS shipped with gettext, this covers the 
major API changes.

My plan now is to start working on tests for the lib, and then tackle 
implementing the gettext(1), msgfmt(1) and msgunfmt(1) tools.

Regarding the project page: 

- What other extensions were added to the .mo format? I couldn't find 
any major changes in the gettext NEWS or Changelog files.

- Are there any other major API items that I'm missing? Looking at 
gettext.h from GNU gettext, it seems that was it.

Here's the code, in case anyone wants to give me early feedback before I 

William Orr

(Continue reading)

Pierre Pronchery | 18 May 00:34 2015

Patch from FreeBSD for el_gets() in libedit

			Hi tech-userlevel <at> ,

FreeBSD patched their own copy of libedit about a month ago, see:
(patch attached)

If I get this right (I have never used libedit myself) the value
returned in the "nread" argument (called "count" in the corresponding
manual page) may be wrong if any wide-character was encountered.

I did not find where el_wgets() is implemented. Would anyone know?

In pkgsrc I saw a folder called "libedit" in net/tnftp/files/libedit,
and it has a completely different implementation of el_gets().

Ok to commit?


--- src/eln.c.orig	2015-03-25 21:02:28.000000000 +0100
+++ src/eln.c	2015-03-28 11:42:29.913925000 +0100
 <at>  <at>  -75,12 +75,17  <at>  <at>  public const char *
 el_gets(EditLine *el, int *nread)
 	const wchar_t *tmp;
+	int nwread;
(Continue reading)

Richard PALO | 17 May 13:26 2015


After first soliciting Amitai's and Tobias' opinion, it was felt best to start here.

First the problem statement:

I came across some issues with pkgsrc using pdksh as primary TOOLS_PLATFORM sh/ksh
under SunOS (illumos).

For example, it segfaults in configure when trying to build ffmpeg010 on i386 (ABI=32).

I isolated it to a problem in the function 'tenter' found in table.c.

In 'struct table' both size and nfree are 'short', so for grins I first tried
simply 'min' with INT32_MAX then decided on setting size & nsize as unsigned shorts 
(avoiding for the moment changing the size of the structure):

> richard <at> omnis:/home/richard/src/pkgsrc/shells/pdksh$ git diff files/table.c
> diff --git a/shells/pdksh/files/table.c b/shells/pdksh/files/table.c
> index 1ac8fc3..9a9e459 100644
> --- a/shells/pdksh/files/table.c
> +++ b/shells/pdksh/files/table.c
>  <at>  <at>  -7,6 +7,9  <at>  <at> 
>  #include "sh.h"
>  #define        INIT_TBLS       8       /* initial table size (power of 2) */
> +#ifndef min
> +#define        min(a, b)       ((a) > (b) ? (b) : (a))
> +#endif
>  static void     texpand     ARGS((struct table *tp, int nsize));
>  static int      tnamecmp    ARGS((void *p1, void *p2));
(Continue reading)

Emmanuel Dreyfus | 13 May 10:27 2015



pthread_key_create() will refuse to create to create more than 
PTHREAD_KEYS_MAX pthread_key_t. I encountered situations
where some Apache setup with various modules could not work 
reliabily on NetBSD because the value is too low. From time
to time the server enters a state where it will not be able
to serve requests.

which should be 128 according to POSIX:
Oddly it is 256 in NetBSD's <limit.h>

The values are:
NetBSD 256
Linux: 1024
MacOS X: 512

Obviously we lag behind and software will suit NetBSD less and less over the
time. Since it is often the result of shared usage by modules from different 
developers, we cannot blame anyone for overflowing _POSIX_THREAD_KEYS_MAX
usage as a requirement.

I suggest for netbsd-7
- fix _POSIX_THREAD_KEYS_MAX to be 128 instad of 256
- increase PTHREAD_KEYS_MAX to 2048 so that we lead again for some time
  this would increase memory footprint of programs linked with -lpthread
  of 14 kB on ILP32 systems, and 28 kB on LP64 systems.

(Continue reading)

Joerg Sonnenberger | 7 May 22:01 2015

POC for more compact default output of apropos

Hi all,
attached patch is based on compla^Wsuggestions from Jared. The goal is
to keep command and short description aligned and limit the snippet to a
single line. More work is needed to properly handle escape sequences and
a trailing elipse, but it would be nice to agree first that this is an
improvement. I'll leave the rest to someone else :)

Attachment (apropos.diff): text/x-diff, 2290 bytes
Brian Ginsbach | 1 May 21:41 2015

Looking for comments on changing strptime(3) %p behavior

The current behavior of strptime(3) and the %p format specifier is
a bit inconsistent/counter-intuitive/surprising.  The results aren't
always what one would expect.  Nor what is seen from other strptime(3)
implementations.  Looking for feedback on the following.

a. strptime(str, "%H %p", &tm)

   Currently if str contains 0-11, for the hour, and a am/pm string
   the time will be adjusted accordingly.  However if the str
   contains 12-23, for the hour, and a am/pm string strptime(3)
   returns NULL (error).  This seems inconsistent if not a bug.

   Does it make sense to apply %p to any hour parsed by %H (or %k)
   as %H implies a 24-hour clock value?  The current code is
   inconsistent; %p is valid with 0-11 while %p is invalid with
   12-23 (strptime(3) returns NULL).  The tm_hour is only adjusted
   when %pm is PM and < 11.

   Would a  more consistent approach would be to not apply %p to
   any 24-hour clock value?  It doesn't necessarily make sense that
   %H (24-hour clock) with %p should be an error regardless of the
   value parsed.  The %p would be parsed but ignored when combined
   with a 24-hour clock.

b. strptime(str, "%p", &tm)

   Currently if str contains a am/pm string and no hour is specified
   then tm_hour is adjusted as per above or an error is returned
   based on tm_hour.  This would seem to be a bug on both counts.

(Continue reading)

Kamil Rytarowski | 24 Apr 06:06 2015

strtoi(3) strtou(3) errata patch


I'm attaching an errata patch for strtoi(3) and strtou(3).

I began to slack off hoping to commit the libc fixes
myself. I was surprised for the inclusion of these two
functions to -7. So it's time to step in again.

Please review and apply the attached patch.

- add strtoi(3) and strtou(3) to namespace.h
- split strtol.3 and strtoi.3
- split strtoul.3 and strtou.3
- note that strtouq(3)/strtoq(3) are BSD legacy functions

Related pending patches:
1. t_strtoi ATF test

After merging I will provide t_strtou.

2. t_strtol improper check of endptr

The above changes should be in NetBSD-7.
Attachment (patch-src_strtoi-and-strtou-errata): application/octet-stream, 23 KiB
Dan Plassche | 10 Apr 17:02 2015

Mounting an ext2fs GPT Partition as a DK Wedge under NetBSD


I'm trying to mount an ext2 partition on a GPT formatted disk attached via
usb 2 under release 6.1.2 on i386. I can mount ffs partitions by dk wedge
number (/dev/dk*), but I get an error when trying to mount an ext2
partition from the same disk:

# mount -t ext2fs -o rw /dev/dk18 /mnt
mount_ext2fs: Warning realpath /dev/dk18: No such file or directory
mount_ext2fs: /dev/dk18 on /mnt: No such file or directory

Is mounting by dk wedge unsupported for filesystems other than ffs


Dan Plassche

carsten.kunze | 4 Apr 19:37 2015

Problem with wcwidth(3)


there may be a problem with the wcwidth(3) function. The C code

#include <locale.h>
#include <stdio.h>
#include <wchar.h>
int main ()
        printf("locale: %s\n", setlocale(LC_ALL, ""));
        printf("wcwidth(0x0301) = %d\n", wcwidth (0x0301));
        printf("wcwidth(0x05B0) = %d\n", wcwidth (0x05B0));
        printf("wcwidth(0x200B) = %d\n", wcwidth (0x200B));

outputs on NetBSD 6.1.5:

locale: C/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/en_US.UTF-8
wcwidth(0x0301) = 1
wcwidth(0x05B0) = 1
wcwidth(0x200B) = 1

which is wrong since all glyphs have zero width.

E.g. output on OpenBSD 5.7 is:

locale: C/en_US.UTF-8/C/C/C/en_US.UTF-8
wcwidth(0x0301) = 0
wcwidth(0x05B0) = 0
wcwidth(0x200B) = 0
(Continue reading)