Re: utf8 input in el_gets(3)

* 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 > > it. > > > > A notable user of this function is sftp(1)

Re: utf8 input in el_gets(3)

Hi Christian & Michael, Michael McConville wrote on Thu, Dec 24, 2015 at 04:19:03PM -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 >> it. Ugh. The amount of indirection

Re: ipmi(4) - Don't check threshold erroneously

On Fri, Dec 25, 2015 at 11:47:19AM +0900, Masao Uebayashi wrote: (snip) > Without learning much about sensor part of IPMI, I think that both reading > bits and "Get Sensor Thresholds Command" work. ... I meant: both ... *should* work.

Re: ipmi(4) - Don't check threshold erroneously

On Fri, Dec 25, 2015 at 11:47:19AM +0900, Masao Uebayashi wrote: > On Tue, Dec 22, 2015 at 09:03:56PM +1000, Jonathan Matthew wrote: > > On Tue, Dec 22, 2015 at 06:42:23PM +0900, Masao Uebayashi wrote: > > > On Mon, Dec 21, 2015 at 03:53:09PM +0100, Mark Kettenis wrote: > > > > > Date: Mon, 21 Dec

bugs in printf(3)

Fourth file, fourth broken file. This is the worst bug found so far. All i'm doing is grepping libc/stdio for "EILSEQ". So far, every single instance i looked at was buggy. I think we should cvs rm libc. The code quality just isn't up to OpwnBSD standards. When fprintf(fp, "...%ls...", ...)

utf8 input in el_gets(3)

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, once the diff is applied. -- Christian

Re: utf8 input in el_gets(3)

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 > > > it. > > > > >

Re: ipmi(4) - Don't check threshold erroneously

On Tue, Dec 22, 2015 at 09:03:56PM +1000, Jonathan Matthew wrote: > On Tue, Dec 22, 2015 at 06:42:23PM +0900, Masao Uebayashi wrote: > > On Mon, Dec 21, 2015 at 03:53:09PM +0100, Mark Kettenis wrote: > > > > Date: Mon, 21 Dec 2015 22:47:19 +0900 > > > > From: Masao Uebayashi

Re: utf8 input in el_gets(3)

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,

bug in fputwc(3) error reporting

Third file, third bug. SO FAR, EACH AND EVERY BLOODY PLACE I LOOKED AT WAS BROKEN. When fputwc(3) encounters an encoding error, it neglects to set the error indicator, just like fgetwc(3) did before i fixed it today. Setting the error indicator is required by the manual and by the standard.

Re: [patch] basename(1) tweaks

>> - activate stack protector > > Hm? Changing the exit to a return does this? yes, stack protector only works if the function returns.

bug in fgetws(3) EOF detection

Crap alert. Seriously. My impression is, whereever you look in the wide character functions in our libc, it's broken. At least, i looked at two files of twenty lines each and found a bug in each of them. I don't believe in luck. I expect more cheap targets. When errno happens to be EILSEQ

Re: [patch] basename(1) tweaks

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

[patch] basename(1) tweaks

Hi tech@, here are some basename(1) tweaks: - remove (void) cast for puts(3) and fprintf(3) - activate stack protector - put includes in correct order --F. Index: basename.c === RCS file: /cvs/src/usr.bin/basename/basename.c,v

Re: [patch] basename(1) tweaks

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.

Re: [patch] basename(1) tweaks

>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

allocation simplifications in yacc

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 ---

Re: allocation simplifications in yacc

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:

Re: [patch] basename(1) tweaks

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. >frit...@alokat.org wrote: >> Hi tech@, >> >> here are some basename(1) tweaks: >> - remove (void)

Re: fgetwc(3) error reporting bug

On Wed, Dec 23, 2015 at 9:27 AM, Ingo Schwarze wrote: > i just noticed a bug in fgetwc(3) in our libc, the function used to > implement getwc(3), getwchar(3), getws(3), getwln(3) and the wscanf(3) > family of functions. In case of an encoding error, it does not set > the error

Re: hashfree, a counterpart to hashinit

Martin Natano wrote: > Hi, > > the diff reads fine to me, except for following nit-picks: It would be > nice if the hashfree() function would check for negative/zero element > counts, like hashinit() does. Also, new functionality should be > documented in the manual. > > Please find below a

mg(1) tranpose-words

This diff adds transpose-words to mg. It behaves slightly differently from emacs when it comes to muliple iterations. Take this text for example: abc def ghi jkl mno pqr If the cursor is on the 'd', then you do C-u 3 M-t, in emacs the result will be: abc ghi jkl mno def pqr The attached diff

[patch] uname(1) tweaks

Hi tech@, here are some tweaks about uname(1): - change the parameter order to the same order as in the manpage - change err(1, NULL) to errx(1, "uname") - change statements like: if (condition) statement if (condition) statement - activate the stack protector --F. Index: uname.c

Re: fgetwc(3) error reporting bug

Ingo Schwarze writes: > Hi, > > i just noticed a bug in fgetwc(3) in our libc, the function used to > implement getwc(3), getwchar(3), getws(3), getwln(3) and the wscanf(3) > family of functions. In case of an encoding error, it does not set > the error indicator, such that a

Re: [patch] uname(1) tweaks

On Thu, Dec 24, 2015 at 01:52:56PM +0100, frit...@alokat.org wrote: > Hi tech@, > > here are some tweaks about uname(1): > > - change the parameter order to the same order as in the manpage > - change err(1, NULL) to errx(1, "uname") Why? This doesn't make sense to me. Like this you'll

Re: hashfree, a counterpart to hashinit

Hi, the diff reads fine to me, except for following nit-picks: It would be nice if the hashfree() function would check for negative/zero element counts, like hashinit() does. Also, new functionality should be documented in the manual. Please find below a regenerated diff including both changes.

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

Dear tech@ readers, On 11/21/15 13:20, Alessandro DE LAURENZIS wrote: > Dear tech@, > > This is an attempt to solve a problem I previously reported [1] to > misc@ (without receiving any feedback, so far). [...] > [1] http://marc.info/?l=openbsd-misc=144800414402238=2 > my second attempt... I

Re: [patch] uname(1) tweaks

frit...@alokat.org(frit...@alokat.org) on 2015.12.24 14:45:51 +0100: > On Thu, Dec 24, 2015 at 02:19:36PM +0100, Theo Buehler wrote: > > On Thu, Dec 24, 2015 at 01:52:56PM +0100, frit...@alokat.org wrote: > > > Hi tech@, > > > > > > here are some tweaks about uname(1): > > > > > > - change the