Re: utf8 input in el_gets(3)

2015-12-25 Thread Nicholas Marriott
Go for it, IIRC there are a few new strcpy that will need care to change to strlcpy but otherwise it should be easy enough. On Thu, Dec 24, 2015 at 04:30:37PM -0500, Christian Heckendorf wrote: > * Michael McConville [24.12.2015. @16:19:03 -0500]: > > > Christian Heckendorf wrote: > > > A cou

memory leak in libc

2015-12-25 Thread fritjof
Hi tech@, it looks like there is a memory leak in libc. In file "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but never freed, when printf(3) is called. --F. $ valgrind --leak-check=full --show-leak-kinds=all /usr/sbin/apm ==29572== Memcheck, a memory error detector ==29572== Copy

Re: memory leak in libc

2015-12-25 Thread Mark Kettenis
> Date: Fri, 25 Dec 2015 11:56:33 +0100 > From: frit...@alokat.org > > Hi tech@, > > it looks like there is a memory leak in libc. In file > "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but > never freed, when printf(3) is called. Not really a leak. That buffer gets freed when f

Re: memory leak in libc

2015-12-25 Thread Ingo Schwarze
Hi Fritjof, frit...@alokat.org wrote on Fri, Dec 25, 2015 at 11:56:33AM +0100: > it looks like there is a memory leak in libc. > In file "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, > but never freed, when printf(3) is called. I think that's a false positive. The pointer to the b

Re: memory leak in libc

2015-12-25 Thread Ingo Schwarze
Hi Mark, Mark Kettenis wrote on Fri, Dec 25, 2015 at 12:30:43PM +0100: > frit...@alokat.org wrote: >> it looks like there is a memory leak in libc. In file >> "src/lib/libc/stdio/makebuf.c" line 62 malloc(3) is called, but >> never freed, when printf(3) is called. > Not really a leak. That buf

Re: allocation simplifications in yacc

2015-12-25 Thread Theo Buehler
On Thu, Dec 24, 2015 at 12:41:28PM -0500, Michael McConville wrote: > 1. realloc acts like malloc when ptr == NULL Why not "#endif", - "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)", - "goto bail;", - "newss = yyss ? (short *)realloc(yyss, newsiz

Re: bugs in printf(3)

2015-12-25 Thread Ingo Schwarze
Hi, more is broken in printf(3). Ingo Schwarze wrote on Fri, Dec 25, 2015 at 12:30:29AM +0100: > Fourth file, fourth broken file. > This is the worst bug found so far. [...] > When fprintf(fp, "...%ls...", ...) encounters an encoding error, > it trashes fp BEYOND REPAIR, clearing all FILE flags,

Re: [patch] Fix tput(1) capability's needed argument count

2015-12-25 Thread Alessandro DE LAURENZIS
Dear tech@ readers, On Thu 24/12/2015 15:58, Alessandro DE LAURENZIS wrote: [...] > my second attempt... I understand that the previous patch was wrong. > > After digging into terminfo(5) man page, I think the problem could be > related to the if...then...else structures (%?...%t...%e...%t...%;)

Re: allocation simplifications in yacc

2015-12-25 Thread Theo Buehler
On Fri, Dec 25, 2015 at 02:34:12PM +0100, Mark Kettenis wrote: > IMNSHO the code produced by OpenBSD's yacc should be portable; > reallocarray isn't portable. ok, thanks for clarifying

Re: allocation simplifications in yacc

2015-12-25 Thread Mark Kettenis
> Date: Fri, 25 Dec 2015 14:17:19 +0100 > From: Theo Buehler > > On Thu, Dec 24, 2015 at 12:41:28PM -0500, Michael McConville wrote: > > 1. realloc acts like malloc when ptr == NULL > > Why not > > "#endif", > - "if (newsize && YY_SIZE_MAX / newsize < sizeof *newss)", > - "

ksh.1: simplify SYNOPSIS a bit

2015-12-25 Thread Michael Reed
Literal pipe characters are easier to read and there isn't any difference in the output for mandoc(1) -Thtml and -Tutf8. \*(Ba is still used elsewhere in ksh.1, although I didn't touch those as I'm unsure if this change is even wanted. Index: ksh.1 ===

ksh.1: Remove $ERRNO reference

2015-12-25 Thread Michael Reed
It's had the ``Not implemented'' notice since ksh.1's initial import 19 years ago [1], so it's probably not going to be implemented. [1]: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1?rev=1.1&content-type=text/x-cvsweb-markup Index: ksh.1 ==

Re: ksh.1: simplify SYNOPSIS a bit

2015-12-25 Thread Jason McIntyre
On Fri, Dec 25, 2015 at 01:23:06PM -0500, Michael Reed wrote: > Literal pipe characters are easier to read and there isn't any > difference in the output for mandoc(1) -Thtml and -Tutf8. > > \*(Ba is still used elsewhere in ksh.1, although I didn't touch > those as I'm unsure if this change is eve

Re: ksh.1: Remove $ERRNO reference

2015-12-25 Thread Alexander Hall
On Fri, Dec 25, 2015 at 01:36:31PM -0500, Michael Reed wrote: > It's had the ``Not implemented'' notice since ksh.1's initial import > 19 years ago [1], so it's probably not going to be implemented. > > [1]: > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/bin/ksh/ksh.1?rev=1.1&content-type=text/x-

Detect more keyboard cases when starting X

2015-12-25 Thread Anthony J. Bentley
Hi, As X starts, it will attempt to detect features from the kbd(8) setting--for example, us.dvorak will enable dvorak in X, and fr.dvorak will enable French dvorak in X. However, it detects these features with equality checks, which will fail if multiple options are set, as in the case of us.dvor

strncpy->strlcpy question

2015-12-25 Thread Ricardo Mestre
Hello, 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 use, plus it will alwa

Re: strncpy->strlcpy question

2015-12-25 Thread Michael McConville
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

Re: strncpy->strlcpy question

2015-12-25 Thread Philip Guenther
On Fri, Dec 25, 2015 at 8:21 PM, 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

Re: mpsafe re(4)

2015-12-25 Thread Jonathan Matthew
On Sat, Dec 05, 2015 at 06:11:51PM +0100, Jonathan Matthew wrote: > The main interesting bit here is the txeof and start loops, which previously > operated based on the prod/cons indices and the contents of the tx queue, > but now just uses the indices as that's the only way to get a consistent vie