Re: Detect more keyboard cases when starting X

On Sat, Dec 26, 2015 at 10:42:10PM +0500, Alexandr Shadchin wrote: > On Fri, Dec 25, 2015 at 05:55:22PM -0700, Anthony J. Bentley wrote: > > 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

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

Please disregard this for now, -m (extended permissions) won't work this way Thanks for the tip tb@ On 18:33 Sat 26 Dec , Ricardo Mestre wrote: > Or even better keep the #ifndef since mknod(8) already has dpath annotation: > > Index: main.c >

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

No thanks. I don't want my shell able to intrinsically create nodes. Let's keep it as it is. Or even better keep the #ifndef since mknod(8) already has dpath annotation: Index: main.c === RCS file:

infinite loop in randomread()/randomwrite()

A read of 2^32 bytes can trigger an endless loop in randomread(), due to integer truncation when passing a size_t argument to min(). There is a similar issue in randomwrite(). The diff included below is a minimal version of a similar diff I've sent to tech@ some months ago, but with peripheral

Re: Detect more keyboard cases when starting X

Hi Anthony, On 26/12/2015 00:55, Anthony J. Bentley wrote: 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

Re: Detect more keyboard cases when starting X

On Fri, Dec 25, 2015 at 05:55:22PM -0700, Anthony J. Bentley wrote: > 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

remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

Hi tech@ Now that dpath annotation in pledge(2) is available then #ifndef MKNOD can be removed and enforce pledge(2) on all codepaths, is this correct, comments? Index: main.c === RCS file: /cvs/src/bin/ksh/main.c,v retrieving

Re: remove #ifndef MKNOD from ksh(1) and enforce pledge(2) on all codepaths

Or even better keep the #ifndef since mknod(8) already has dpath annotation: Index: main.c === RCS file: /cvs/src/bin/ksh/main.c,v retrieving revision 1.75 diff -u -p -u -r1.75 main.c --- main.c 14 Dec 2015 13:59:42 -

Re: Mention lang/go and lang/rust in faq8.html

Michal Mazurek wrote: > Go and Rust are now widely used. It might be worth mentioning them in > the FAQ. ok mmcc@ Thanks! > Index: faq8.html > === > RCS file: /cvs/www/faq/faq8.html,v > retrieving revision 1.268 > diff -u -p

Mention lang/go and lang/rust in faq8.html

Go and Rust are now widely used. It might be worth mentioning them in the FAQ. Index: faq8.html === RCS file: /cvs/www/faq/faq8.html,v retrieving revision 1.268 diff -u -p -r1.268 faq8.html --- faq8.html 24 Nov 2015 00:20:25 -

Re: utf8 input in el_gets(3)

Christian Heckendorf said: > > I remember someone recently mentioning that libedit is due for an > > update. Maybe we should try to include this in a full sync. > > Assuming someone isn't already working on it, I volunteer. I work on it, and I sit on a huge diff for some time. I'll send it out

Clarify factor(6)

Index: factor.6 === RCS file: /cvs/src/games/factor/factor.6,v retrieving revision 1.12 diff -u -p -r1.12 factor.6 --- factor.624 Jan 2011 00:42:44 - 1.12 +++ factor.626 Dec 2015 08:56:37 - @@ -58,7 +58,7 @@ When

Zlib regression tests

Hi, I was bored a bit and noticed the latest zlib version contains tests in example.c. I've cleaned up the file and added it to regress framework. The testsuite shouldn't output anything if all is well. I've changed the types quite a bit so someone with better understanding of C and Zlib should

Re: Detect more keyboard cases when starting X

On 26/12/2015 17:37, Sevan Janiyan wrote: > Hi Anthony, > > On 26/12/2015 00:55, Anthony J. Bentley wrote: >> 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

Re: Clarify factor(6)

On Sat, Dec 26, 2015 at 09:57:57PM +, Jason McIntyre wrote: > On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote: > > Index: factor.6 > > === > > RCS file: /cvs/src/games/factor/factor.6,v > > retrieving revision 1.12

iwn timeouts

I've been running -current on a ThinkPad X201 for close to a year now. iwn times out after about 45-90 seconds every time I boot. This happens very reliably, regardless of which network I'm connecting to. All I get to the syslog is: > Dec 26 17:05:40 thinkpad /bsd: iwn0: timeout waiting for

Re: Clarify factor(6)

On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote: > Index: factor.6 > === > RCS file: /cvs/src/games/factor/factor.6,v > retrieving revision 1.12 > diff -u -p -r1.12 factor.6 > --- factor.6 24 Jan 2011 00:42:44 -

Re: bug in fputwc(3) error reporting

Ingo Schwarze writes: [...] > 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. Hmm, the C standard and POSIX

Re: Clarify factor(6)

On Sat, Dec 26, 2015 at 11:09:35PM +0100, Theo Buehler wrote: > On Sat, Dec 26, 2015 at 09:57:57PM +, Jason McIntyre wrote: > > On Sat, Dec 26, 2015 at 10:01:34AM +0100, Michal Mazurek wrote: > > > Index: factor.6 > > > === > > >

Re: bugs in printf(3)

Ingo Schwarze writes: > 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

Re: bug in fputwc(3) error reporting

Hi Jérémie, Jérémie Courrèges-Anglas writes: > Hmm, the C standard and POSIX have slightly different texts regarding > this. > > Quoting POSIX-2013: > -->8-- > RETURN VALUE > > Upon successful completion, fputwc() shall return wc. Otherwise, it > shall return WEOF, the error indicator

Re: bug in fputwc(3) error reporting

"Anthony J. Bentley" writes: > Hi Jérémie, Hi, > Jérémie Courrèges-Anglas writes: >> Hmm, the C standard and POSIX have slightly different texts regarding >> this. >> >> Quoting POSIX-2013: >> -->8-- >> RETURN VALUE >> >> Upon successful completion, fputwc() shall