Re: refine canaries

Daniel Micay wrote: > Not quite as good as a random value per canary, but a random value per > page would already be pretty fine-grained and each canary can still be > made unique via something like the current `random ^ hash(address)`. One thing to remember is that a number of architectures are

Re: Does grep need a version?

Michael McConville wrote: > It's been 0.9 since the original import in 2003... note we also have --mmap for the sole purpose of compat. i'd say keep it. anything that *does* check the version will get a number it doesn't like and then do something "sensible".

Re: [PATCH] doas authentication type

Stuart Henderson wrote: > > > > Personally my take on this is that as long as it's just done as -a > > then it's small and simple to implement (pass a string from args to > > auth_userokay), and there's no other way to provide access to this which > > is an important, though lesser-known, part of

Re: ksh(1): utf8 in emacs editing mode

Sebastien Marie wrote: > While testing ksh, I found the following problem, that I will try to > describe. But I dunno if it is just a case no-managed by your patch. It > looks like a problem in "inserting a UTF-8 char inside the line (opposed > to 'at end of line')". This is what Ingo meant by

kevent ktrace

allow some inspection of the kevent structs. Index: kern/kern_event.c === RCS file: /cvs/src/sys/kern/kern_event.c,v retrieving revision 1.67 diff -u -p -r1.67 kern_event.c --- kern/kern_event.c 5 Dec 2015 10:11:53 -

Re: OpenBSD errata, Dec 3, 2015

Bob Beck wrote: > Fixes have been commited for both CVE-2015-1394 and CVE-2015-1395. > CVE-2015-1394 warrants an errata. > The errata for CVE-2015-1394 is available for OpenBSD 5.8 and OpenBSD > 5.7 from the master site as well as the mirrors: To clear up any confusion, the CVE numbers should be

Re: libc: getusershell, new implementation

Tobias Stoeckmann wrote: > > And I still think that the current code is a bit too permissive in parsing > things. I mean what's the point in allowing lines like: > > sometextwithoutspace/bin/ksh should be used for logins # seriously! > > Which would result in /bin/ksh, by the way. > > Didn't

Re: libc: getusershell, new implementation

Tobias Stoeckmann wrote: > There's still a possible overflow in getusershell.c. We could increase > the buffer allocation yet again, but I have to agree with the glibc > developers here: enough is enough. The code is ugly and has proven to be > difficult to review. Another approach is to rewrite

Re: __progname in base

Tobias Stoeckmann wrote: > Opinions, thoughts? looks good, but you've got some mostly unrelated changes in here. this should be separate, but ok for the rest. > > Index: sbin/newfs_ext2fs/newfs_ext2fs.c > > === > > RCS file:

ip6 fragment nibble

Cleaner this way I think. Index: frag6.c === RCS file: /cvs/src/sys/netinet6/frag6.c,v retrieving revision 1.65 diff -u -p -r1.65 frag6.c --- frag6.c 22 Oct 2015 10:22:53 - 1.65 +++ frag6.c 3 Dec 2015 11:44:10 -

Re: WAPBL: Adding the FFS capability to alloc files contiguously

Bob Beck wrote: > On Fri, Nov 27, 2015 at 02:50:57PM -0200, Walter Neto wrote: > > You have a number of places here where you introduce a line of 8 spaces > after your #endif - please clean up the trailing spaces, they shouldn't be > there. > > You also have uses of B_METAONLY that are not

rm bonus inet6 option

We have a socket option guarded by ifdef _KERNEL that therefore cannot be used by userland (nor used in kernel). No pcb code tests for the flag either. Index: netinet/in_pcb.h === RCS file: /cvs/src/sys/netinet/in_pcb.h,v retrieving

Re: WAPBL: Adding the FFS capability to alloc files contiguously

Walter Neto wrote: > > You also have uses of B_METAONLY that are not inside a #ifdef WAPBL in > > ffs_balloc.c > > > > Yeah, but I don't know what is the best way to correct it. > Should I use: > #ifdef WAPBL > foo(..., flags | B_METAONLY, ...); > #else > foo(..., flags, ...); >

Re: doas password prompt

Vadim Zhukov wrote: > 2015-12-02 12:40 GMT+03:00 Ted Unangst <t...@tedunangst.com>: > > henning points out that if you are seven levels deep when doas asks for a > > password, it can be hard to tell who is asking for what password. > > > > modify the prompt to

doas password prompt

henning points out that if you are seven levels deep when doas asks for a password, it can be hard to tell who is asking for what password. modify the prompt to include the program name and user@host. Index: doas.c === RCS file:

Re: Completely disable 2D acceleration on Broadwell

Peter Hessler wrote: > On 2015 Dec 02 (Wed) at 17:13:32 +1100 (+1100), Jonathan Gray wrote: > :On Tue, Dec 01, 2015 at 04:44:39PM +0100, Mark Kettenis wrote: > :> As tedu@ reported (and some pople on misc@ confirmed) partly disabling > :> 2D acceleration on Broadwell made X unstable. It really

rm bge supported devices

There are many other product lists, but starting with the two big broadcom flavors here. I've had a dozen machines with bge, but none of them were listed in the man page. I don't think these product lists are helpful. 1. If you have a device and want to know if it's supported, there's no reverse

malloc canaries and validation

This is a variant of the diffs sent by Daniel Micay, and then assembled by Theo Buehler. I've looked it over and made a few tweaks. One: validate the junk in malloc hasn't been touched. I've tweaked this to always be on if junk is on, but to only check the first 32 bytes. (Without the atexit()

Re: lex(1) allocation cleanup

Michael McConville wrote: > Theo de Raadt wrote: > > > > If it is not our own fork -- then stay away from this. It is > > > > pointless putting increasing delta into code which does not run in > > > > risk environments. > > > > > > I thought we had already made that decision based on tedu's

Re: move scorefile + pledge for robots(6)

Theo Buehler wrote: > Robots has a nicely implemented score file, so I decided not to touch > it, except for moving to $HOME by default. Needs pledge("getpw") > because of that. I think some combination of $LOGNAME, $USER, and getlogin() should suffice for that. I mean, getlogin() alone should

Re: what approach for TRNG?

Devin Reade wrote: > A while ago a posted a dmesg for a TRNG USB device (the MoonBase Otago > OneRNG) per > . > > I'm looking at adding support for this device but haven't splunked too >

Re: Move score and log files to $HOME for snake(6)

Theo Buehler wrote: > > If you're not going to maintain a list of high scores of the user, you > could still simplify snscore() further: The score file will just > contain the user's score as a short, so you could get the user name > using getlogin(2) instead of doing getuid() getpwuid(), etc. >

Re: implementation of cut -c

Ingo Schwarze wrote: > > The insight that Ted asked for is that > > * in contrast to the other programs (ls, rs, ul), cut(1) isn't >merely doing the same things with multibyte characters that it >used to do with single byte characters; it grows substantial >new, user-visible

Re: pledge fish(6) plus a few more things

Ricardo Mestre wrote: > Prodded by theo@ and others offline, the removal of the pager may cause > some terms to not display the entire text of the instructions for fish(6). > > After some rewording, removal of blank lines and start the paragraphs > with 2 spaces the text fits at least in a 80x24

Re: Remove function from less(1)

Ricardo Mestre wrote: > There's no need to have a handrolled function for a simple compare that > is just used once throughout all the source, or should it be kept for > code readability? > if ((info->search_type & SRCH_NO_REGEX) == 0) > - return

Re: [patch] tail(1) follow multiple files

Stuart Henderson wrote: > This is broken: > > $ echo moo | tail -c +2 > > > From an older working system: > > $ echo moo | tail -c +2 > oo yes, same as the case with lines which i hack/fixed. martijn sent me a patch, pending review.

Re: [patch] was: Re: login(3) routines data integrity patch

Chris Turner wrote: > On 11/12/15 14:10, Ted Unangst wrote: > > Chris Turner wrote: > >>> > >>> The attached patch calls fsync(2) on related FD's in the login(3) > >>> routines, which corrected the problem on my test machine, > >>> and imho

Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]

> > Modified files: > > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c > > tail.c > > > > Log message: > > another try to allow tailing multiple files. maybe it works? > > commit now to allow people to test. > > I just updated to very latest snapshot and

Re: [PATCH 1/2] flex 2.5.39

Serguey Parkhomovsky wrote: > * renamed parse.c, parse.h, scan.c, skel.c with init prefix so compiling > flex outside of obj by accident wouldn't clobber the bootstrap files Do you remember what caused you to skip using the in base yacc? The diff below seems to work for me. Index: Makefile

Re: tail -n +NUM broken [Was CVS: cvs.openbsd.org: src]

Ted Unangst wrote: > > > Modified files: > > > usr.bin/tail : extern.h forward.c misc.c read.c reverse.c > > >tail.c > > > > > > Log message: > > > another try to allow tailing multiple files. maybe it works? >

Re: Question about shm_open and sem_open

游俊德 wrote: > Hello, > > I have a question about source code of shm_open and sem_open functions. > > int > shm_open(const char *path, int flags, mode_t mode) > { > (skipped) > > if (sb,st_uid != getuid()) { > close(fd); >errno = EPERM; >

Re: apmd ignoring ENXIO on /dev/apmctl

Jan Stary wrote: > Upon startup, apmd(8) opens /dev/apmctl like this: > > if ((ctl_fd = open(fname, O_RDWR | O_CLOEXEC)) == -1) { > if (errno != ENXIO && errno != ENOENT) > error("cannot open device file `%s'", fname); > } > > Why is it that we

Re: printf(3) wording

Jason McIntyre wrote: > On Tue, Nov 17, 2015 at 06:14:33PM +0100, Jan Stary wrote: > > On Nov 17 17:06:11, j...@kerhand.co.uk wrote: > > > On Tue, Nov 17, 2015 at 10:38:41AM +0100, Jan Stary wrote: > > > > I am not a native speaker, but the conversion specifiers > > > > are "interpreted" by

ypserv h

Really wants ndbm.h, not dbm.h. Also, memory.h is spelled string.h now. Index: yppush/yppush_svc.c === RCS file: /cvs/src/usr.sbin/ypserv/yppush/yppush_svc.c,v retrieving revision 1.14 diff -u -p -r1.14 yppush_svc.c ---

Re: Reducing compilation warnings in imsg.c on FreeSBD

Craig Rodrigues wrote: > I tried the following and was able to compile without warning: > > Index: imsg.c > === > --- imsg.c (revision 290924) > +++ imsg.c (working copy) > @@ -74,7 +74,7 @@ > > again: > if

Re: [patch] tail(1) follow multiple files

Martijn van Duren wrote: > Isn't anyone willing to take a stab at this patch? > > On 11/09/15 12:56, Martijn van Duren wrote: > > ping > > > > On 11/04/15 23:29, Martijn van Duren wrote: > >> Hello tech@, > >> > >> I got somewhat annoyed by the fact that OpenBSD's tail can't follow > >> multiple

Re: pledge for tetris

Theo Buehler wrote: > In its current form, tetris is a setgid program and needs a whopping > > pledge("stdio rpath wpath cpath flock getpw id tty") > > throughout its lifetime because of the score file in /var/games. > > As discussed with Theo off-list, this is risk-only. Thus, drop the >

Re: pledge for tetris

Ted Unangst wrote: > Theo Buehler wrote: > > In its current form, tetris is a setgid program and needs a whopping > > > > pledge("stdio rpath wpath cpath flock getpw id tty") > > > > throughout its lifetime because of the score file in /var/game

Re: utf8 in rs

Ingo Schwarze wrote: > I think that way we can actually start committing such patches and > improve our userland. > > Two final notes: > > 1. It turns out each of the three programs needs exactly one > multibyte-character helper function in utf8.c, and each helper > function uses

Re: MALLOC_STATS and pledge

David CARLIER wrote: > Hi all, > > I ve tried to discuss this point with Otto Moerbeek but he might be > very busy so I throw the topic here if you do not mind ... > > I have the habit to enable MALLOC_STATS but with the recent pledge > feature, it s now difficult to debug some pledged

Re: pledge("stdio") for arch(1)/machine(1)

Ingo Schwarze wrote: > Hi, > > Theo de Raadt wrote on Fri, Nov 13, 2015 at 08:21:41AM -0700: > > Theo Buehler wrote: > > >> This straightforward pledge("stdio") is one of the last uncommitted ones > >> from Theo's big 'tame in userland' diff and seems to have been > >> overlooked so far. > > >

Re: open(2) with hardcoded values

Ricardo Mestre wrote: > Hi! > > After a quick grep on the tree I found a few places where open(2) is > still used with hardcoded numeric values. > > I sent this to Theo for reviewing, but he might not had the time for it > so here it goes: When you send patches, can you base them in a single

Re: [patch] was: Re: login(3) routines data integrity patch

Chris Turner wrote: > > Wondering if anyone had a chance to take a look at these - > Subject line tagged accordingly :D > > I could see in some scenarios, aside from generating incorrect > > data, this incorrect record could be used to facillitate hiding > > presence of a successful compromise.

Re: [PATCH 1/2] flex 2.5.39

Serguey Parkhomovsky wrote: > Hi tech@, > > There was recent discussion in having a new version of flex in base, as > our current version (2.5.4) is ancient. I have prepared a patch that > will update it to 2.5.39, taking a few examples from NetBSD's and > FreeBSD's flex. > > The patch is

Re: more utf8 less ebcdic

Nicholas Marriott wrote: > How about just lose chardef[] entirely now? ok, was thinking about the same.

Re: export directive in make

Carlin Bingham wrote: > GNU make and NetBSD's bmake (which is also used by FreeBSD) > support this. > > This is based on the implementation from bmake. Do you have a makefile that needs this? I think adding features that exist elsewhere, but not adding all of GNU compat (which we're clearly not

Re: Periodically sync RTC

Christian Weisgerber wrote: > I would like to sync the system time periodically back to the RTC. > > Currently we update the RTC > (1) when the time is set with clock_settime() or settimeofday(), which > never happens for a typical ntpd setup, > (2) before suspend, > (3) when the system is

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Michael McConville wrote: > Nicholas Marriott wrote: > > Looks good, ok nicm > > Reviewing now, generally looks good. > > A few things: > > I don't understand the motive for all the err() -> errx() and fatal() -> > fatalx() changes. If I came across these, I probably would have > suggested the

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Tobias Stoeckmann wrote: > > > > > + i = vsnprintf(str, len, fmt, ap); > > > > > va_end(ap); > > > > > > > > > > - if (i == -1 || i >= (int)size) > > > > > - fatal("xsnprintf: overflow"); > > > > > + if (i < 0 || i >= (int)len) > > > > > +

Re: unify xmalloc (was Re: [patch] cvs: retire xfree())

Tobias Stoeckmann wrote: > Is this okay for ssh and tmux, which are out to be very portable? > Nicholas mentioned that malloc is not required to set errno. I've also > checked the standard and it's just an extension. Although at worst, > the user sees a wrong error message... Are they portable to

save less

less has a peculiar estrdup function. unlike ecalloc etc., it only prints an error but doesn't quit. But the callers don't seem to check for null. And in many places they call a function called save() instead. It is clearer to make estrdup() quit and use it everywhere. Index: cmdbuf.c

Re: more utf8 less ebcdic

Ted Unangst wrote: > Oops, that was the big bomb diff. We want to keep the nl_langinfo and some > charset support. Just remove the environment variable and pare down some of > the stranger charsets. here's better working second half of the big bomb. we can init the charset table with

less less chardef

This removes the "rarely" used LESSCHARDEF env. The next diff will be for LESSCHARSET, but I'm content to ax one branch at a time. Index: charset.c === RCS file: /cvs/src/usr.bin/less/charset.c,v retrieving revision 1.12 diff -u -p

Re: execless wump

Christian Weisgerber wrote: > "Ted Unangst": > > > here's a nickel kid, get a terminal with scrollback... > > We could have just deleted less(1)! > I think you are going overboard here. If you really want to delete > the exec, at least replace it with a m

more utf8 less ebcdic

Having to define LESSCHARSET to print the special characters doesn't seem that useful. It doesn't do translation. So setting it to ebcdic isn't going to magically make such files appear correctly in my xterm. There seem to be two possibilities: 1. You have LESSCHARSET and LC_CTYPE set to the same

Re: more utf8 less ebcdic

Ted Unangst wrote: > Having to define LESSCHARSET to print the special characters doesn't seem that > useful. It doesn't do translation. So setting it to ebcdic isn't going to > magically make such files appear correctly in my xterm. > > There seem to be two possibilities

less ppp in getty

Sorry, uh, not tested... Index: main.c === RCS file: /cvs/src/libexec/getty/main.c,v retrieving revision 1.38 diff -u -p -r1.38 main.c --- main.c 16 Oct 2015 22:25:50 - 1.38 +++ main.c 5 Nov 2015 22:57:52 - @@

execless wump

here's a nickel kid, get a terminal with scrollback... Index: wump.c === RCS file: /cvs/src/games/wump/wump.c,v retrieving revision 1.26 diff -u -p -r1.26 wump.c --- wump.c 29 Aug 2013 20:22:22 - 1.26 +++ wump.c 5

delete execl from phantasia

Just deleting the option to play again seems easier than figuring out why a loop won't work like any normal program. Just push the up arrow and hit enter if you want to play again. Index: io.c === RCS file:

less time

time_t is not a long. Index: funcs.h === RCS file: /cvs/src/usr.bin/less/funcs.h,v retrieving revision 1.9 diff -u -p -r1.9 funcs.h --- funcs.h 5 Nov 2015 22:08:44 - 1.9 +++ funcs.h 5 Nov 2015 22:44:47 - @@

Re: [1/3] replace setbuf(3) etc by setvbuf(3) - cat, sed & top

Frederic Nowak wrote: > Hi there, > > setbuf(3) etc "are obsoleted by setvbuf(3)" and "should be avoided". thanks!

Re: Another uvm(9) tweak

Michael McConville wrote: > It's probably best to say that UVM_MAPFLAG() returns a uvm_flag_t. It's > almost exclusively used for uvm_map()'s flag arg, which has that type. > Of course, it's an arithmetic macro, so it doesn't actually have a > return type. I would argue we should delete some of

Re: Drop register keyword from less(1)

Todd C. Miller wrote: > On Mon, 02 Nov 2015 09:16:07 +, Nicholas Marriott wrote: > > > I looked briefly at this and it wouldn't be that hard. However, while it > > would be fantastic to clean up all the crap from less, it isn't clear if > > Garrett D'Amore is going to be keeping his fork up

Re: should pledge(2) allow raise(3) and abort(3)?

Theo Buehler wrote: > While playing with Daniel Micay's malloc patches, I ran into a lot of > pledge aborts since pledge("stdio") disallows raise(3) and abort(3). > That's because raise sends the to 'pid + THREAD_PID_OFFSET' instead > of the pid itself. The first sentence of the comment and the

tidy up pledge_ioctl

The last argument is always a file, so we can type it instead of using void. Also, as a safety belt, leave vp null if the file type isn't vnode. Index: kern/kern_pledge.c === RCS file: /cvs/src/sys/kern/kern_pledge.c,v retrieving

Re: calloc -> malloc in get_data() and get_string()

Joerg Jung wrote: > > > > Am 28.10.2015 um 17:05 schrieb Michael McConville : > > > > Relayd, httpd, and ntpd define the functions get_data() and > > get_string(). Both call calloc and then immediately memcpy. Calloc's > > zeroing isn't optimized out. These functions are

Re: Oct 15 OpenBSD errata and LibreSSL releases

Constantine Aleksandrovich Murenin wrote: > So you confirm that using block scope in such scenario is the new best > practice now? I don't think it was ever not best practice; though whether people do it or not is a separate matter.

Re: utf8 hack for ls

Anthony J. Bentley wrote: > Stefan Sperling writes: > > On Mon, Oct 26, 2015 at 03:58:58PM -0600, Anthony J. Bentley wrote: > > > "Ted Unangst" writes: > > > > it only gets deeper and thicker... > > > > > > Indeed. > > > &

Re: utf8 hack for ls

Anthony J. Bentley wrote: > "Ted Unangst" writes: > > Fixing citrus is a pretty massive effort in itself. I'd prefer to see the > > replacement code prove itself as a separate API first, then we can remove > > citrus and change the wchar functions to use the ne

Re: mini utf-8 hexdump

Stuart Henderson wrote: > On 2015/10/27 06:51, Ted Unangst wrote: > > This adds a quite limited understanding of utf-8 to hexdump. I've found it > > helpful trying to see exactly what's coming out of some utilities instead of > > trying to decode utf-8 by hand. &

uptime in top

when i run top, i think uptime would be interesting info to include. there's some space on the second line under the hostname and time. i tried to squeeze it on the first line, but there isn't much room with 80 columns. Index: display.c

Re: utf8 hack for ls

Damien Miller wrote: > rather than scattering hacks in each program that needs to > output utf8 to the console, how about making something > for libutil that they all can use? Yes, that is certainly the plan, but I think it's easier to see what's needed if we convert a few programs first to

pwcache

Old bug in pwcache functions. Calling setpassent(1) to keep the passwd database open is a surprising abstraction violation for the caller of user_from_uid. Now it has a file descriptor it must close before exec by calling endpwent(), but this fact is not mentioned. (find is affected by this, for

Re: pwcache

Todd C. Miller wrote: > On Mon, 26 Oct 2015 11:39:48 -0400, "Ted Unangst" wrote: > > > This improves the cache. Basically, it's kind of like four way > > associative now, with LRU replacement. Also we can cache nameless > > entries instead of going back to g

Re: pwcache

Philip Guenther wrote: > On Mon, Oct 26, 2015 at 6:47 AM, Ted Unangst <t...@tedunangst.com> wrote: > > Old bug in pwcache functions. Calling setpassent(1) to keep the passwd > > database open is a surprising abstraction violation for the caller of > > user_from_uid. N

Re: __predict_false for pledge

Michael McConville wrote: > Ted Unangst wrote: > > Michael McConville wrote: > > > We have a pretty strong guarantee that it can only happen once per > > > process... > > > > I don't think this really matters. What does it do to the assmembly, &

Re: utf8 hack for ls

Ted Unangst wrote: > Christian Weisgerber wrote: > > On 2015-10-23, "Ted Unangst" <t...@tedunangst.com> wrote: > > > > >> To what degree should tools like ls protect terminals from escape codes? > > > > > > I think this is beyond t

Re: pledge(2) in quiz(6)

Jan Stary wrote: > Any comments/OK? > > On Oct 22 13:49:28, h...@stare.cz wrote: > > games/quiz.c popen()s a PAGER to display the help message. > > Throw that away and let the use pipe into a PAGER if needed. > > Then we can just pledge "stdio rpath". yeah, works for me.

ftpd banner

unifdef some foolishness. note that BSD is not currently defined when this file is built. Index: ftpcmd.y === RCS file: /cvs/src/libexec/ftpd/ftpcmd.y,v retrieving revision 1.60 diff -u -p -r1.60 ftpcmd.y --- ftpcmd.y18 Aug 2015

Re: support for malloc allocation canaries

Daniel Micay wrote: > This patch adds an opt-in malloc configuration option placing canaries after > small allocations to detect heap overflows on free(...). It's intended to be > used alongside guard pages for large allocations. Since it's essentially > adding extra padding to all small

Re: pair(4) (was: connect routing domains on layer 2)

Reyk Floeter wrote: > Hi, > > as requested by Theo and discussed with many, the following diff moves > it into a new driver. This also allowed to improve the logic of link > states related to the connection (as discussed with Claudio). > > The new driver is called pair(4). > > # ifconfig

Re: unify errno messages

Alexander Bluhm wrote: > Hi, > > Before removig nls, I would like to unify all error messages in > - include comment > - libc comment > - nls C > - man page > > The EPROGUNAVAIL change is just beautification. Any objections > against that? ok

Re: does anoybody use ul?

Nicholas Marriott wrote: > Well, it does work: > > printf 'A\bA_\bB'|ul > > I still think it is not useful, I say kill it. Oh! Is that how you use it? The man page doesn't explain, apparently expecting that everybody just knows there's only one true way to mark up text.

Re: does anoybody use ul?

Stefan Sperling wrote: > On Fri, Oct 23, 2015 at 05:50:53AM -0400, Ted Unangst wrote: > > well, it doesn't work with utf-8 because it tries to underline only half the > > character. i'm aiming for the "quick fix"... > > Why not at least try a kind of bett

Re: does anoybody use ul?

Christian Weisgerber wrote: > On 2015-10-23, "Ted Unangst" <t...@tedunangst.com> wrote: > > > ul appears somewhat useless for its intended purpose. > > mandoc /usr/share/man/man1/ls.1 | ul > > Works fine. Of course that functionality has been i

utf8 hack for ls

So, third diff to ponder as we evaluate this approach. This one also uses a u8len() function to help get the column widths correct. (Still not dealing with combining or otherwise not 1 width glyphs.) Index: ls.c === RCS file:

Re: utf8 hack for ls

Nicholas Marriott wrote: > Hi > > This doesn't account for UTF-8 double width characters, so they will > still throw the column widths off? right. maybe we will steal some code from tmux for that :). but getting u8len() into the right places is the first step. i don't think we want a isu8cont()

Re: utf8 hack for ls

Stefan Sperling wrote: > This removes the isprint() check entirely. Do we really want that? > > To what degree should tools like ls protect terminals from escape codes? I think this is beyond the scope of what ls should care about. du doesn't have such a check. Does the shell perform a check

Re: utf8 hack for ls

Peter Hessler wrote: > As a different approach to ls, I wrote this a while ago. This uses the > wchar_t functions, but only in putname(). This will correct the alignment of columns, but if you have a filename like pöp the columns will be super wide instead of nicely

Re: does anoybody use ul?

Christian Weisgerber wrote: > Ted Unangst: > > > --- ul.c10 Oct 2015 16:15:03 - 1.19 > > +++ ul.c23 Oct 2015 10:29:43 - > > @@ -241,6 +241,8 @@ mfilter(FILE *f) > > obuf[col].c_mode |= BOLD|mode; > > e

utf8 in rs

rs doesn't print nicely aligned columns with utf-8 inputs. there's a few ways to handle this; here's just one. note that the source is riddled with lots of code like: if (maxlen < p - *ep) /* update maxlen */ maxlen = p - *ep; I'm very scared to try

Re: WAPBL implementation

Walter Neto wrote: > Hi guys, sorry for the inconvenience. > > Once you only have use git at console, cvs is nightmare :( > > But I am learning :) this indeed looks a lot better. although it's quite the diff to review. some brave soul testing of this might be appreciated.

does anoybody use ul?

ul appears somewhat useless for its intended purpose. echo _xxx_ | ul does not result in underlined text in an xterm, so I doubt many people are using this. Unlike, say, mandoc, it can't output Greek letters. I also imagine most people have moved on to some form of markdown for their other text

Re: Oct 15 OpenBSD errata and LibreSSL releases

André Schneider wrote: > Hi, > > maybe i'm overlooking something, but in the rebuild and install > instructions, > shouldn't it say >cd /usr/src/lib/libcrypto > instead of >cd src/lib/libcrypto either or. maybe somebody has their src somewhere else.

Oct 15 OpenBSD errata and LibreSSL releases

The OBJ_obj2txt function in libcrypto contains a one byte buffer overrun and memory leak, as reported by Qualys Security. This can be abused by an attacker to cause a denial of service in some cases. Patches are now available for OpenBSD as well as new releases of LibreSSL portable. 5.6, 5.7, and

Re: nsd 4.1.6rc1

Stuart Henderson wrote: > It does not build as-is, there's an issue with "c_get_text" (a renamed > yyget_text) with our version of flex. I have two possible workarounds > so far but neither is particularly nice; > > - add a configlexer.c file generated with newer flex to the tree (e.g. > the one

less crypt in chpass

Remove some more of the crypt() calls in login_chpass. Index: login_chpass/Makefile === RCS file: /cvs/src/libexec/login_chpass/Makefile,v retrieving revision 1.7 diff -u -p -r1.7 Makefile --- login_chpass/Makefile 22 Apr 2014

Re: sleep: don't return errno from main()

Philip Guenther wrote: > On Sun, Oct 11, 2015 at 8:19 AM, Ted Unangst <t...@tedunangst.com> wrote: > > agreed, but why not return 1? i don't want to have to slap 2>/dev/null > > around > > all my sleep calls now. > > So don't. Why would you need to? doesn't err() print a message?

Re: Permitting the override of MACHINE_ARCH in amd64/param.h

Sevan Janiyan wrote: > > > On 12/10/2015 16:30, Theo de Raadt wrote: > > You have failed to explain the usage case; I don't believe there is > > any scenario where people benefit from more architecture divergence. > > As an example, in pkgsrc, CPUs architectures are grouped under a common >

Re: sleep: don't return errno from main()

Philip Guenther wrote: > > As a general rule, programs should not use errno values as an exit status. > > Compare "sleep 10001" w/ and w/o this diff. > > ok? agreed, but why not return 1? i don't want to have to slap 2>/dev/null around all my sleep calls now. > > Index: sleep.c >

<    2   3   4   5   6   7   8   9   10   11   >