multibyte mail(1), was: Epilogue

Hi Walter, Walter Alejandro Iglesias wrote on Thu, Oct 12, 2023 at 09:42:33AM +0200: > Given that I'm the OP of this thread It seems you mean the thread "mail(1) MIME support". > I feel entitled to officially closing it. I have no idea what "closing" means. > Those interested in my proposal

Re: /bin/ls print format bugs

Hi Crystal, Crystal Kolipe wrote on Tue, Oct 03, 2023 at 06:47:42PM -0300: > Two display format bugs seems to have crept in to ls due to the > addition of scaled human readable values and large minor numbers. I think you are right that the current situation isn't good. Thank you for bringing

Re: List tracepoints directly in kdump.1

Hi Christian, Christian Weisgerber wrote on Thu, Sep 28, 2023 at 07:01:29PM +0200: > It's always the same: > * foobar doesn't behave as expected > * I ktrace foobar > * I run kdump... too much information. > * I check the kdump(1) man page, since I can't remember which letter > represents

Re: Fix function names in imsg_init.3

Hi Lucas, Lucas wrote on Thu, Sep 28, 2023 at 04:07:02PM +: > There is no imsg_seek_set_n{32,64}, but imsg_set_n{32,64}. Committed, thanks. Ingo > diff refs/heads/master 34767f41b5371661bc7d3b47c3f780279d1bcd9c > commit - c7bb30c9e72387bdcf13f2516a8d63c49f7eae54 > commit +

Re: Buffer overflow in /usr/bin/deroff

Hi, up front, thanks for finding and fixing this and sorry for not coming round to testing the patch before commit. Crystal Kolipe wrote on Wed, Sep 27, 2023 at 06:04:01PM -0300: > On Wed, Sep 27, 2023 at 02:05:14PM -0600, Todd C. Miller wrote: >> As written, deroff will not emit a line that

Re: Send international text with mail(1) - proposal and patches

Hi, i fear this is getting a bit out of hand... Stefan Sperling wrote on Thu, Sep 21, 2023 at 02:12:50PM +0200: > On Thu, Sep 21, 2023 at 01:25:01PM +0200, Walter Alejandro Iglesias wrote: >> I corrected many of the things you pointed me, but not all. The >> function I use to check utf8 is

Re: Send international text with mail(1) - proposal and patches

Hi, i checked the following points: * Even though RFC 2049 section 2 bullet point 1 only *requires* MIME-conformant MUAs to always write the header "MIME-Version: 1.0" - and mail(1) is most certainly not MIME-conformant - RFC 2049 section 2 bullet point 8 explicitly *recommends* that

Re: Send international text with mail(1) - proposal and patches

Hi Kirill, Kirill Miazine wrote on Wed, Sep 20, 2023 at 12:52:52PM +0200: > you may not even need -m, and instead inspect LC_CTYPE environment > variable and add appropriate headers for UTF-8. according to locale(1), > LC_CTYPE may be set to indicate UTF-8: > > If the value of LC_CTYPE ends

Re: Send international text with mail(1) - proposal and patches

Hi Walter, i did not look closely at the patch yet, and i did not dig for standards documents, which one should almost certainly do before committing such a patch unless one knows all the relevant standards by heart (which i do not), so i'm not saying this must be done differently, but instead i

Re: man 9 intro - improvements [and learning for me]?

Hi Christoff, of course you are free to work on whatever interests you, but if you are looking for advice, i'd respectfully recommend that you try to work on specifics rather than on generalities first, in particular when you feel as if your experience in contributing isn't above average. That

Re: Add ENOTDIR as possible error to unveil(2)

Hi, Janne Johansson wrote on Sat, Sep 16, 2023 at 11:49:10AM +0200: > In case someone wants the change in a diff format, those 5 seconds > of work are available here: > http://c66.it.su.se:8080/obsd/unveil.2.diff How come jj@ forgot we want diffs inline? > +.It Bq Er ENOTDIR > +.Fa path >

Re: bsd.port.mk.5: Ev for NO_ARCH

Hi Caspar, Caspar Schutijser wrote on Wed, Sep 06, 2023 at 01:46:45PM +0200: > The patch below marks up "NO_ARCH" consistently with the other > variables. I noticed because on man.openbsd.org, NO_ARCH looks off > compared to the others: > https://man.openbsd.org/bsd.port.mk.5#MULTI_PACKAGES

Re: sysctl: Fixing "second level name in XX. is invalid" on trailing period

Hi Neel, Neel Chauhan wrote on Tue, Aug 29, 2023 at 02:36:57PM -0700: > On 2023-08-29 14:23, Theo Buehler wrote: >> Neel Chauhan: >>> + if (string[strlen(string) - 1] == '.') >>> + buf[strlen(string) - 1] = '\0'; >> Careful with out-of-bounds accesses. What if string is "" ?

Re: Removing extra space in "sysctl: top level name in . is invalid"

Hi Neel, Neel Chauhan wrote on Tue, Aug 29, 2023 at 02:48:54PM -0700: > I have noticed a bug. When running "sysctl ." or "sysctl kern." without > my other patch, I get an extra space between "name" and "in": >> sysctl: top level name in . is invalid Technically, that message is correct.

Re: Pull Request: Addition of String Data Type in /sys/sys/types.h

Hi, Abderrahmane Ghellab wrote on Sun, Jun 18, 2023 at 08:16:21AM +0100: > I am writing to discuss a recent pull request I submitted Never submit pull requests, for no reason whatsoever, full stop. There is no excuse for doing that (except in a few related projects like OpenSSH-portable). >

Re: route.8: markup route flags to get tags

Hi Klemens and Jason, Jason McIntyre wrote on Wed, Apr 05, 2023 at 07:12:05PM +0100: > On Wed, Apr 05, 2023 at 01:07:18PM +, Klemens Nanni wrote: >> To find out what a particular letter means, you must arrive at this list >> why generic means because the first column has no markup. >> >> As

Re: mem.4: be more accurate about securelevel

Hi Stuart, Stuart Henderson wrote on Fri, Jan 20, 2023 at 08:50:48AM +: > On 2023/01/18 12:46, Theo de Raadt wrote: >> But you should not start a sentence with also. >> Also you should not start a sentence with but. >> >> Not the best english. jmc can weight in perhaps. >> Jan Klemkow

Re: Inconsistent isdigit(3) man page

Hi Todd, hi Bob, Todd C. Miller wrote on Fri, Jan 20, 2023 at 09:59:20AM -0700: > On Fri, 20 Jan 2023 09:32:38 -0700, Bob Beck wrote: >> So isdigit(3) says in the first paragraph that >> 'The complete list of decimal digits is 0 and 1-9, in any locale.' The intended meaning of this sentence was

Re: libevent manuals

Hi Ted, Ted Bullock wrote on Mon, Jan 16, 2023 at 12:56:06PM -0700: > The impetus is that the event(3) manual page isn't all that good for > documenting how to use the library and it is missing functions that are > included in the API and available in the shared library. That seems true, and

Re: [RFC resend v1 2/2] Use arc4random_range() instead of arc4random_uniform() when appropriate

Hi Alejandro, Alejandro Colomar wrote on Sun, Jan 01, 2023 at 01:08:17AM +0100: > On 12/31/22 20:08, Alejandro Colomar wrote: >> This makes the code much more readable and self-documented. While doing >> this, I noticed a few bugs, and other cases which may be bugs or not. >> Switching to this

Re: [v3] timeout.9: document missing interfaces, miscellaneous rewrites

Hi Scott, in the NAME section, please put timeout_add_nsec after timeout_add_usec to agree with the order in the SYNOPSIS. In any case, please go ahead. It appears jmc@ is developing a sore elbow from more than a year of medicine ball ping pong. ;-) The following are merely suggestions /

Re: [RFC resend v1 2/2] Use arc4random_range() instead of arc4random_uniform() when appropriate

Hi Alejandro, Alejandro Colomar wrote on Sat, Dec 31, 2022 at 08:08:14PM +0100: > This makes the code much more readable and self-documented. I object. I is a needless detour that invites confusion and bugs. In C code, it is customary to deal with half-open intervals, and closed intervals are

Re: [RFC v1 1/2] Add arc4random_range(min, max)

Hi Alexandro, i fail to see the point. We do not usually add extra functions if the same effect can be be attained with one-liners. There is significant value in keeping the API as small as possible, it makes the API easier to learn and it makes programming mistakes less likely. On top of

Re: getdelim.3: Add a missing Vt

Hi Josiah, committed, thanks! Ingo Josiah Frentsos wrote on Tue, Dec 20, 2022 at 12:49:06PM -0500: > Index: getdelim.3 > === > RCS file: /cvs/src/lib/libc/stdio/getdelim.3,v > retrieving revision 1.6 > diff -u -p -r1.6 getdelim.3

Re: args vs arg ... in manuals

Hi Klemens, Jason McIntyre wrote on Tue, Dec 20, 2022 at 10:35:19AM +: > On Tue, Dec 20, 2022 at 09:36:39AM +, Klemens Nanni wrote: >> Both styles are used, but I argue that the former fails to distinguish >> between >> $ program 'args in one shell word' >> and >> $ program one

Re: pause.3: misc cleanup

Hi Scott, Scott Cheloha wrote on Sat, Dec 10, 2022 at 09:25:48AM -0600: > Sure, I will keep the ERRORS section. > I think the current phrasing in ERRORS is odd, though. > "may set the global variable..." is what we normally say here, but it > isn't a "may" in this case, it's an "always". I

Re: pause.3: misc cleanup

Hi Scott, thanks for repeatedly working on time-related library documentation. :-) Unless noted otherwise, i agree with Todd's comments. Todd C. Miller wrote on Wed, Nov 09, 2022 at 10:31:15AM -0700: > On Wed, 09 Nov 2022 16:47:22 +, Scott Cheloha wrote: >> RETURN VALUES >> >> - Pull

Re: strtonum.3: Use the proper macro for "long long"

Hi, yes, this is completely correct, with one tiny exception that should be fixed while committing, see in-line below. Jason, since you already started working on this, could you please commit this patch with OK schwarze@? I'm surprised there was still so much .Li in our tree where .Vt should

Re: [patch] rename tbl man pages

Hi Daniel, Daniel Dickman wrote on Thu, Jul 07, 2022 at 12:03:18AM -0400: > Over a decade ago there was some work in bsd.man.mk to build tbl pages > with mandoc. For example this commit from 2010: > > > revision 1.32 > date: 2010/10/17 22:47:08; author: schwarze;

Re: [PATCH] Fix typo in ed(1) manpage

Hi Jason, Jason McIntyre wrote on Sun, Jun 19, 2022 at 06:51:26AM +0100: > On Sat, Jun 18, 2022 at 11:17:43PM +, S M wrote: >> Sending a separate patch as this is unrelated to my previous e-mail. > fixed, thanks. Thanks. > i note that the same text is present in regress/usr.bin/diff/t11.1

Re: [PATCH] man - apmd(8) reference

Hi, wdaver wrote on Sun, Jun 19, 2022 at 02:09:06PM -0700: > Ah - mangl returns Whoa, i wasn't even aware that "mangl" exists, but it appears it does exist and we even have a port for it: sysutils/mangl. It isn't very happy on my machine, though: schwarze@isnote $ mangl mangl

Re: apmd(8): reconnecting AC, not battery

Hi Jason, Jason McIntyre wrote on Sat, May 28, 2022 at 05:10:08PM +0100: > On Sat, May 28, 2022 at 10:34:35AM +0100, Stuart Henderson wrote: >> On 2022/05/28 06:52, Jason McIntyre wrote: >>> On Fri, May 27, 2022 at 07:19:37PM +0200, Jan Stary wrote: apmd says: When the power

Re: bwfm(4): show modulation type for the various chipsets

Hi Stuart, Stuart Henderson wrote on Sat, Apr 23, 2022 at 06:52:46PM +0100: > saves time if you want to ignore 11n-only devices. ok? Adding useful information is good in general, but i can't really comment on the content. If you add a column to a -column list, usually you also want to update

Re: Security support status of xnf(4) and xbf(4)

Hi Demi Marie, Demi Marie Obenour wrote on Fri, Mar 25, 2022 at 12:13:59PM -0400: > Linux’s netfront and blkfront drivers recently had a security > vulnerability (XSA-396) that allowed a malicious backend to potentially > compromise them. In follow-up audits, I found that OpenBSD’s xnf(4) >

Re: __read_mostly

Hi, >> A downside of this is that it becomes easier to guess the addresses >> of the tagged variables. > No kidding. It partly undoes the effort of KARL. I don't feel qualified to comment on the patch, but i can't resist mentioning that i still love tedu@'s classical dictum "attack

Re: mandoc.1: update example to reflect current options

Hello Anders, Anders Damsgaard wrote on Tue, Feb 08, 2022 at 08:36:11AM +0100: > The mandoc(1) option alias -l for -a was removed from the documentation > in revision 1.107: > > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/mandoc.1.diff?r1=1.106=1.107 > > The -l option still

Re: rev(1): pull MB_CUR_MAX out of the hot loop

ert@ for his feedback. Ingo > On Sun, 2022-01-09 at 00:45 +0100, Ingo Schwarze wrote: >> Index: rev.c >> === >> RCS file: /cvs/src/usr.bin/rev/rev.c,v >> retrieving revision 1.13 >> diff -u -p -r1.

Re: rev(1): pull MB_CUR_MAX out of the hot loop

Oopsie... Ingo Schwarze wrote on Sun, Jan 09, 2022 at 12:45:27AM +0100: > # Demonstate broken error handling in the old code. > >$ ./obj/wrap /obin/rev >$ echo $? > 42 Stupid me, this is what i meant, of course: $ ./obj/wrap /oldbi

Re: rev(1): pull MB_CUR_MAX out of the hot loop

Hi, Martijn van Duren wrote on Sat, Jan 08, 2022 at 08:30:20AM +0100: > Why not go for the following diff? > It has a comparable speed increase, but without the added complexity > of a second inner loop. Actually, i like the idea of not duplicating the loop, in cases where that is possible

Re: rev(1): pull MB_CUR_MAX out of the hot loop

Hi Scott, thank you for spending quite some work on our small utility programs, and sorry for failing to follow up as often as i should. Scott Cheloha wrote on Fri, Jan 07, 2022 at 09:45:41AM -0600: > In rev(1), we call MB_CUR_MAX for every byte in the input stream. > This is extremely

Re: rpki-client: check ipAddrBlock and autonomousSysNum for criticality

Hi Claudio, Claudio Jeker wrote on Sat, Dec 25, 2021 at 05:48:53PM +0100: > On Sat, Dec 25, 2021 at 11:36:50AM +0100, Theo Buehler wrote: >> These extensions MUST be marked critical by the sections of the spec >> mentioned in the cryptowarnx(). That's determined by the ASN1_BOOLEAN >> that is

Re: document patch(1) not supporting binary diffs

Hi Theo, Theo de Raadt wrote on Mon, Dec 20, 2021 at 10:37:00AM -0700: > Ingo Schwarze wrote: >> The patch(1) manual talks about "lines" throughout, >> and for binary files, a concept of "lines" does not even exist. > That is a bit strong. Some ut

Re: document patch(1) not supporting binary diffs

Jason McIntyre wrote on Mon, Dec 20, 2021 at 04:13:19PM +: > i'm ok with your diff Thanks for checking. > but it is slightly misleading in context of > reading from stdin. i suppose that is no biggie. I think i see why you say so. Speaking *formally*, what we usually do is describing what

Re: document patch(1) not supporting binary diffs

Hi Christopher, Christopher Zimmermann wrote on Mon, Dec 20, 2021 at 04:01:49PM +0100: > base patch cannot work with diffs of binary files. It might help to say > so in the manpage since other implementations do support this (ab)use of > patch. OK? I agree you are pointing out a slight

Re: Fix typo in '}' command in less.1

Hi Richard, Richard Ulmer wrote on Fri, Dec 10, 2021 at 04:04:11PM +0100: > this is just a minor copy-and-paste error fix for the less(1) man page. Committed, thank you. > I also contributed this upstream: https://github.com/gwsw/less/pull/228 > > I hope this is the right mailing list for

Re: Explicitly tag commands in vi(1)

Hi Simon, Simon Branch wrote on Sat, Nov 20, 2021 at 03:10:22PM -0800: > Here's a diff that adds explicit .Tg macros to vi(1), We don't want that: $ man -O tag=Tg mdoc [...] In most cases, adding a Tg macro would be redundant because mandoc(1) is able to automatically tag most

Re: diff: improve legibility of structs in several manpages

Hi Jan, sorry that i failed to look at this earlier. Even with your diff, the style is still not completely consistent. I think that inside .Bd -literal, the best style is exactly the same as in source code: structname{ typename; type*name; }; where * can be more than one tab if some of

Re: locale in expr(1)

Hi Marc, Marc Espie wrote on Mon, Nov 15, 2021 at 05:06:23PM +0100: > On Mon, Nov 15, 2021 at 03:43:47PM +0100, Jan Stary wrote: >> On Nov 10 18:46:08, h...@stare.cz wrote: >>> On Nov 10 18:15:44, h...@stare.cz wrote: expr(1) says expr1 {=, >, >=, <, <=, !=} expr2

Re: Typo in ASN1_STRING_length.3

Hi Matthias, Matthias Schmidt wrote on Sun, Nov 14, 2021 at 10:41:40AM +0100: > in the recent commit to ASN1_STRING_length.3 a typo sneaked in: Committed. Thank you for reading such patches and for reporting the error! Yours, Ingo > diff 96921f4986cebab89014f4b188cc00426e2e11d8 /usr/src >

Re: locale in who(1)

Hi, Martijn van Duren wrote on Wed, Nov 10, 2021 at 02:03:51PM +0100: > I see no reason to keep it. > OK martijn@ if anyone wants to commit this. Done. > On Wed, 2021-11-10 at 13:37 +0100, Jan Stary wrote: >> Why does who(1) need to setlocale()? On some systems, setlocale(LC_TIME) influences

Re: [patch] httpd static gzip compression

Hi Theo, Theo de Raadt wrote on Thu, Nov 04, 2021 at 08:27:47AM -0600: > prx wrote: >> On 2021/11/04 14:21, prx wrote: >>> The attached patch add support for static gzip compression. >>> >>> In other words, if a client support gzip compression, when "file" is >>> requested, httpd will check if

Re: uniq: add HISTORY section

Hi Todd, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:20:47AM -0600: > uniq appeared in research Unix version 3. OK schwarze@. If - like in this case - the indicated release is the first one in any system to ever contain the feature, and not just the first one among the direct ancestors of

Re: uniq(1): ignore newline when comparing lines?

Hi, Todd C. Miller wrote on Tue, Nov 02, 2021 at 08:12:00AM -0600: > On Mon, 01 Nov 2021 21:04:54 -0500, Scott Cheloha wrote: >> Yes it would be simpler. However I didn't want to start changing the >> input -- which we currently don't do -- without discussing it. >> >> The standard says we

Re: demystify vport(4) in vport(4) and ifconfig(8)

Hi Stuart, Stuart Henderson wrote on Fri, Oct 29, 2021 at 01:59:38PM +0100: > On 2021/10/29 14:08, Ingo Schwarze wrote: >> Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: >>> On 2021/10/28 23:19, Klemens Nanni wrote: >>>> On Fri, Oct 29, 2021 at 1

Re: demystify vport(4) in vport(4) and ifconfig(8)

Hi Stuart, Stuart Henderson wrote on Fri, Oct 29, 2021 at 10:53:41AM +0100: > On 2021/10/28 23:19, Klemens Nanni wrote: >> On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: >>> MANPAGER=firefox man -T html $(ifconfig -C) >> This doesn't work if fi

Re: demystify vport(4) in vport(4) and ifconfig(8)

Hi Klemens, Klemens Nanni wrote on Thu, Oct 28, 2021 at 11:19:30PM +: > On Fri, Oct 29, 2021 at 12:57:54AM +0200, Ingo Schwarze wrote: >> MANPAGER=firefox man -T html $(ifconfig -C) > This doesn't work if firefox is already running It is true that it sometimes works and som

Re: demystify vport(4) in vport(4) and ifconfig(8)

Hi, Sebastian Benoit wrote on Thu, Oct 28, 2021 at 11:05:54PM +0200: > We tend to forget that there are other output formats for manpages > as well. right now, i can got to https://man.openbsd.org/ifconfig and > jump from there to all of these manpages. With them removed, i can no > longer do

Re: Missing include in sys/device.h

Hi Rafael, Rafael Sadowski wrote on Tue, Sep 28, 2021 at 08:22:06AM +0200: > On Mon Sep 27, 2021 at 11:20:55PM -0600, Theo de Raadt wrote: >> Oh, like how about you try compiling a kernel after your proposed diff? >> >> in userland - >>size_t comes from sys/types.h >>or a header file

Re: Unwind + NSD usage question

Hello Paul, Paul de Weerd wrote on Tue, Sep 28, 2021 at 12:44:07PM +0200: > 'local-data-ptr:' in unbound.conf(5): > http://man.openbsd.org/unbound.conf#local~2 > http://man.openbsd.org/unbound.conf#local~3 heh, thank you for *both* of these bug reports, i'm adding them to the mandoc TODO file

Re: OpenBSD `ftp` port for MSVC (Windows)

Hi Samuel, first, note that this is off-topic on tech@. If you see a need to continue the thread, please move it to misc@. Samuel Marks wrote on Sun, Sep 05, 2021 at 02:10:14PM -0400: > WiP, basically just started this: >

Re: man sed(1) diff

Hello, i see where Ian's confusion is coming from, even though arguably, the existing text is accurate. But it is not a good idea to insert exceptions as parenthetic remarks in the middle of an enumeration of steps that is already somewhat long and complicated. I think it is better to explain

Re: timeout: Prettify man page and usage

Hi Jason, Jason McIntyre wrote on Sat, Sep 04, 2021 at 09:47:12PM +0100: > pretty damning that my ok is on that commit ;) > i'll try to remember... Heh. With the amount of work you are doing - your current commit count stands at 9113, on average 1.34 per day, during a time of over eightteen

Re: timeout: Prettify man page and usage

Hi Jason, Jason McIntyre wrote on Fri, Sep 03, 2021 at 02:46:47PM +0100: > On Fri, Sep 03, 2021 at 03:42:21PM +0200, Ingo Schwarze wrote: >> Theo de Raadt wrote on Thu, Sep 02, 2021 at 09:57:11AM -0600: >>> I think we should list shorts, and longs which have no shorts. >&

Re: mark getsubopt(3) as part of POSIX

Hi Theo, as you sent it, your patch is misleading since our manual page describes two features that are not required by POSIX. So i propose the larger patch shown below instead. While here, clarify what "null-terminated" means. It matters for this page in particular because the page talks

Re: timeout: Prettify man page and usage

Hi, Theo de Raadt wrote on Thu, Sep 02, 2021 at 09:57:11AM -0600: > I think we should list shorts, and longs which have no shorts. I agree, and i think we arrived at the same conclusion in the past. It applies to both usage() and SYNOPSIS, and ideally, both should match, except maybe in very

Re: rm.1: remove extraneous word

Hi Jason, Jason McIntyre wrote on Fri, Sep 03, 2021 at 07:47:19AM +0100: > On Thu, Sep 02, 2021 at 11:10:54PM +0100, Jason McIntyre wrote: >> i wonder if it was originally an attempt to not quote posix >> (or posix attempting to not quote bsd). posix refers to removing >> "directory entries",

Re: Atomic signal flags for vi(1)

Hi Tim, trondd wrote on Wed, Sep 01, 2021 at 08:46:28PM -0400: > Ingo Schwarze wrote: >> Ingo Schwarze wrote on Wed, Sep 01, 2021 at 04:38:51PM +0200: >>> Note that the h_hup() and h_term() signal handlers are still unsafe >>> after this commit because they also set t

Re: timeout: execvp(2) return is always an error

Hi Sebastien, Sebastien Marie wrote on Thu, Sep 02, 2021 at 09:09:43AM +0200: > If execvp(2) returns, it is always an error: there is no need to check > if the return value is -1. Just unconditionally call err(3). > > Comments or OK ? OK schwarze@ Ingo > timeout: execvp(2) should not

Re: Atomic signal flags for vi(1)

Hi, Ingo Schwarze wrote on Wed, Sep 01, 2021 at 04:38:51PM +0200: > Note that the h_hup() and h_term() signal handlers are still unsafe > after this commit because they also set the "killersig" (how fitting!) > field in a global struct. I like it when fixing two bugs on

Re: Atomic signal flags for vi(1)

Hi Tim, trondd wrote on Tue, Aug 24, 2021 at 07:45:33PM -0400: > "Theo de Raadt" wrote: >> +h_alrm(int signo) >> +{ >> + GLOBAL_CLP; >> + >> + F_SET(clp, CL_SIGALRM); >> >> F_SET is |=, which is not atomic. >> >> This is unsafe. Safe signal handlers need to make single stores to

Re: averse to lisp in base?

Hi, Tomasz Rola wrote on Sun, Aug 29, 2021 at 08:21:03PM +0200: > On Sun, Aug 29, 2021 at 03:27:27AM +0200, mayur...@kathe.in wrote: >> Would the core team consider including a minimalist lisp in the base? >> e.g. http://t3x.org/klisp/index.html [...] > If I would want to propose any Lisp into

Re: Atomic signal flags for vi(1)

Hi Theo, Theo de Raadt wrote on Sun, Aug 29, 2021 at 11:38:18AM -0600: > Ingo Schwarze wrote: >> *If* more than one GS object ever existed and/or the .gp pointers >> in different SCR objects could point to different GS objects, this >> patch might change behaviour.

Re: Atomic signal flags for vi(1)

Hi, Theo de Raadt wrote on Sun, Aug 29, 2021 at 02:54:57AM -0600: > This does look better. > > I appreciate that you are fixing this underlying problem first, before > overlaying your timer diff. Indeed. > Is this working for the vi crowd? *If* more than one GS object ever existed and/or the

Re: allow KARL with config(8)'d kernels

Hi, Theo de Raadt wrote on Sun, Aug 29, 2021 at 07:15:34AM -0600: > I am not thrilled with the name "kernel.conf". > It does not seem intuitively discoverable. What would be a canonical name? It is a command file for config(8). Note that the "config-file" for config is something else, and

Re: cal(1): Clean up mutually exclusive options

Hi Theo, Theo de Raadt wrote on Mon, Aug 16, 2021 at 08:15:03AM -0600: > Jason McIntyre wrote: >> well, in those cases i think the authors shared the viewpoint that >> mutually exclusive means you can;t mix them but in this case it is >> essentially not an error to do so, and so documented it

Re: cal(1): Clean up mutually exclusive options

Hi Jason, Jason McIntyre wrote on Mon, Aug 16, 2021 at 12:02:13PM +0100: > when i wrote my mail, i failed to understand that "overrides earlier" > was really just another way of saying "mutually exclusive". That is incorrect. This is what "mutually exclusive" means (without further

Re: cal(1): Clean up mutually exclusive options

Hi Theo, Theo de Raadt wrote on Sun, Aug 15, 2021 at 05:42:13PM -0600: > Is it really reasonable that we should strictly follow a non-applicable > standard in such rarely used non-standard utilities, Not strictly, no. Usefulness needs to be considered in individual cases. There is value in

Re: cal(1): Clean up mutually exclusive options

Hi Jason, Jason McIntyre wrote on Sun, Aug 15, 2021 at 11:30:05PM +0100: > can't we take a stance that where options override each other, > the last one wins? Yes, that is possible. Cases exist where one option overrides another and order does not matter - for example, "lock -n -t -1" is the

Re: cal(1): Clean up mutually exclusive options

Hi Martijn, Martijn van Duren wrote on Sun, Aug 15, 2021 at 11:40:49PM +0200: > To quote schwarze in the jot mutually exclusive thread: > On Fri, 2021-08-13 at 11:48 +0200, Ingo Schwarze wrote: >> In this case, even though this is not a POSIX command, POSIX utility >>

Re: fresh prompt after Ctrl-C in cdio(1)

Hi, Christian Weisgerber wrote on Thu, Aug 12, 2021 at 06:31:56PM +0200: > Ingo Schwarze: >> deraadt@ recently pointed out to me in private mail that it is good >> for usability if interactive programs providing line editing >> functionality are consistent what they do

Re: jot(1): make -b -c and -w mutually exclusive

Hi Martijn, Martijn van Duren wrote on Fri, Aug 13, 2021 at 08:51:42AM +0200: > So here's the first one: > - When -b is set, but followed by -w it doesn't remove the boring flag > and the -w is interpreted as a -b string I agree that can't be quite right. > - -c is defined as "This is an

Re: fresh prompt after Ctrl-C in cdio(1)

Hi Martijn, Martijn van Duren wrote on Thu, Aug 12, 2021 at 04:37:24PM +0200: > Maybe I've used cdio once or twice and I don't have a cd-player at hand > (at least connected to my workstation) to test this. So purely from code > inspection: You set the signal handler before entering el_gets and

fresh prompt after Ctrl-C in cdio(1)

Hi, deraadt@ recently pointed out to me in private mail that it is good for usability if interactive programs providing line editing functionality are consistent what they do with Ctrl-C, ideally discard the current input line and provide a fresh prompt. At least that is what bc(1), ftp(1),

libedit: stop playing hopeless games with FIONBIO

Hi, in its current state, the editline(3) library is completely unfit to work with non-blocking I/O. Neither the API nor the implementation are even designed for that purpose. I do have some candidate ideas to minimally extend the API - without adding any new functions - to also work with

Re: date -j and seconds since the Epoch

Hi, > ok gerhard@ Thanks for reporting, for the initial patch, and for checking the final one. This now committed. Yours, Ingo >> Index: date.c >> === >> RCS file: /cvs/src/bin/date/date.c,v >> retrieving revision 1.56 >> diff

Re: libedit: stop ignoring SIGINT

Hi Martijn, Martijn van Duren wrote on Mon, Aug 09, 2021 at 02:15:42PM +0200: > If we're stripping down fixio to a single function, why not > inline the whole thing? I deliberately tried to: 1. Keep patches that change behaviour as small as possible to make review as simple as possible

libedit: stop ignoring SIGINT

Hi, as mentioned earlier, deraadt@ reported that sftp(1) ignores Ctrl-C. Fixing that without longjmp(3) requires making editline(3) better behaved. Currently, when read(2) from the terminal gets interrupted by a signal, editline(3) ignores the (first) signal and unconditionally calls read(2) a

Re: libedit: read__fixio cleanup

Hi Martijn, Martijn van Duren wrote on Mon, Aug 09, 2021 at 11:04:35AM +0200: > Btw, would there be any benefit to declare zero as const in this > context? I dont think so. At least according to the ioctl(2) manual page, FIONBIO expects an int * argument, not a const int *. Yours, Ingo

libedit: read__fixio cleanup

Hi, deraadt@ recently reported to me that the editline(3) library, while line editing is active - for example inside el_gets(3) - ignores the first SIGINT it receives, for example the the first Ctrl-C the user presses. I consider that a bug in the editline(3) library. Some programs, for example

Re: less(1): refreshing file of size 0 results in file being treated as a pipe

Hi, thank you for reporting this bug and for providing a patch to fix it. I just committed your patch. Also thanks to tb@ and deraadt@ for cross-checking the patch. Yours, Ingo user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500: > Oops, forgot that OpenBSD doesn't have ! capability in

Re: date -j and seconds since the Epoch

Hi, sorry for the afterthought, i just noticed that the Subject: line is misleading. This patch has nothing to do with -j. If -j is not specified, this patch changes the value passed to adjtime(2) or settimeofday(2), which arguably matters even more than something merely printed on stdout.

Re: date -j and seconds since the Epoch

Hi Gerhard and Bryan, Gerhard Roth wrote on Mon, Aug 02, 2021 at 10:36:05AM +0200: > Bryan Vyhmeister found a strange behavior in date(1): > > # date -f %s -j 1627519989 > Thu Jul 29 01:53:09 PDT 2021 > # date -u -f %s -j 1627519989 > Thu Jul 29 00:53:09 UTC 2021 > >

Re: less(1): refreshing file of size 0 results in file being treated as a pipe

Hi, after quite some head-scratching, i consider the following bug report legitimate: user wrote on Thu, Aug 05, 2021 at 12:43:21AM -0500: > On Thu, Aug 05, 2021 at 12:37:00AM -0500, user wrote: >> On Fri, Jul 23, 2021 at 11:15:59AM -0500, user wrote: >>> Less contains a hack to force files of

Re: time.3: miscellaneous cleanup and rewrites

Hi Scott, since i see this wasn't committed yet, it is OK schwarze@, too. Consider leaving the .Nd alone since both jmc@ and millert@ recommended that, and use "That version counted the time" in the HISTORY section as recommended by jmc@. I think you should indeed remove the sentence about

Re: Add versioned lib to system perl's @INC for non-packaged modules

Hi, thanks to sthen@ for providing more background! so the bottom line seems to be that, once the code changes are tested, committed, and prove stable and once people come round to it, moving the site manual page directories out of /usr/local/man/ and making them versioned in exactly the same

Re: Add versioned lib to system perl's @INC for non-packaged modules

Hi Andrew, Andrew Fresh wrote on Fri, Jul 30, 2021 at 05:34:40PM -0700: > On Sun, May 16, 2021 at 03:30:39PM -0700, Andrew Hewus Fresh wrote: >> There do appear to be some annoyances with still shared directories for >> man pages, in that if you install a CPAN module and then attempt to >>

Re: sleep.3: miscellaneous cleanup and rewrites

Hi Scott, Scott Cheloha wrote on Tue, Jul 27, 2021 at 05:15:09PM -0500: > On Mon, Jul 26, 2021 at 10:37:03AM -0600, Todd C. Miller wrote: >> On Mon, 26 Jul 2021 07:55:00 -0500, Scott Cheloha wrote: >>> Still wondering whether we need an Errors section to mention that >>> sleep(3) can set errno.

Re: nanosleep.2: miscellaneous cleanup

Hi Scott, Scott Cheloha wrote on Wed, Jul 21, 2021 at 11:02:00AM -0500: [ EFAULT ] > Given deraadt@'s response I'm just going to leave the existing > language. Fine with me. > I guess I will need to dig into it a bit. Finding the text of the > really early documents, prior to SUSv2, is

Re: nanosleep.2: miscellaneous cleanup

Hi Theo, Theo de Raadt wrote on Tue, Jul 20, 2021 at 08:14:20PM -0600: > Ingo Schwarze wrote: >> [EFAULT] foo points outside the process's allocated address space. >> >> But i don't really i like that. The word "allocated" makes me wonder >> because it

Re: nanosleep.2: miscellaneous cleanup

Hi Scott, Scott Cheloha wrote on Tue, Jul 20, 2021 at 05:20:16PM -0500: > The nanosleep.2 page could use some cleanup. Here's a bunch of fixes, > rewrites, etc. > > I've included my notes on the changes below. I have some (mostly > stylistic) questions in there, too. Thanks for explaining

  1   2   3   4   5   6   7   8   9   10   >