Re: locale in comm(1)

Hi, Jan Stary wrote on Thu, Jan 10, 2019 at 09:30:19PM +0100: > Does comm(1) need to setlocale(3)? schwarze@cvs $ grep -A 2 '\' ~/TODO-UTF8.txt comm - character case folding (non-standard '-f' flag) [requires wcscasecmp(3)] So yes, it does need setlocale(LC_CTYPE, ""), and no, this diff

Re: LC_TIME in calendar(1)

Hi, Jan Stary wrote on Thu, Jan 10, 2019 at 08:24:58PM +0100: > calendar imho doesn't need to setlocale(LC_TIME, ...) > before and after strftime(3), as LC_TIME is ignored. As it stands, this diff is not OK. The calendar(1) program is also calling setlocale(LC_ALL, "") from main, both in the pa

Re: Virtio 1.0 for the kernel

arm64 also uses this subsystem, and as a result this diff breaks all those kernels. You ask how to run arm64 Uhm, you didn't even try to compile it.

Re: Virtio 1.0 for the kernel

On Thu, Jan 10, 2019 at 11:38:38PM +0100, Stefan Fritsch wrote: > Hi, > > the diff below implements the virtio 1.0 standard in the kernel (0.9 keeps > working, of course). It's not ready for commit, yet, but I would like some > input. > > For the most part, the changes from 0.9 to 1.0 are not t

Re: locale in locate(1)

Scott Cheloha wrote: > > On Jan 10, 2019, at 14:35, Jan Stary wrote: > > > > Does locate(1) need to setlocale(3)? > > locate(1) uses tolower(3), the results of which can be affected by > locale settings. locate(1)'s database is, at least in theory, portable. > If you don't explicitly set the lo

Re: locale in locate(1)

> Does locate(1) need to setlocale(3)? Since you ask the question, yes. Oh wait, was your question rhetorical? It lacks facts. Who's time are you wasting? > Index: locate/locate.c > === > RCS file: /cvs/src/usr.bin/locate/locate/

Re: locale in locate(1)

Scott Cheloha wrote: > The ctype wizard may also have a very elegant explanation clarifying > whether this is correct or not. The diffs received are annoying. What problem does it solve? What are the downsides? Is there any education in the diffs as to why the changes are needed, so that peop

Re: locale in locate(1)

> On Jan 10, 2019, at 14:35, Jan Stary wrote: > > Does locate(1) need to setlocale(3)? locate(1) uses tolower(3), the results of which can be affected by locale settings. locate(1)'s database is, at least in theory, portable. If you don't explicitly set the locale to POSIX/C I think it might be

Virtio 1.0 for the kernel

Hi, the diff below implements the virtio 1.0 standard in the kernel (0.9 keeps working, of course). It's not ready for commit, yet, but I would like some input. For the most part, the changes from 0.9 to 1.0 are not that big, but there are some notable differences. Since some headers are also

ospf(6)d: fix "redistribute X set type 2 depend on if"

Hi tech, in OSPFs external LSAs the type is encoded in the metric field. ospfd and ospf6d overwrite the type information when "depend on" is used and the specified interface is down (or in backup state). Below diff fixes this. The problem was reported on misc by Ior Podlesny: https://marc.info/?l

Re: LC_TIME in calendar(1)

Jan Stary wrote: > calendar imho doesn't need to setlocale(LC_TIME, ...) > before and after strftime(3), as LC_TIME is ignored. iirc, our current practice is to delete locale related calls where the functionality isn't implemented, so this and the other diffs are ok.

Re: install(1) could fail due to race

On Mon, Jan 07 2019 14:27:29 -0700, Todd C. Miller wrote: > The main difference with -S is that you end up with two copies of > the target file on disk for a short period of time. That was a > bigger deal back when -S was added. Today, it probably doesn't > matter. so, how about this patch then?

locale in locate(1)

Does locate(1) need to setlocale(3)? Jan Index: locate/locate.c === RCS file: /cvs/src/usr.bin/locate/locate/locate.c,v retrieving revision 1.31 diff -u -p -r1.31 locate.c --- locate/locate.c 19 Nov 2015 21:46:05 -

locale in comm(1)

Does comm(1) need to setlocale(3)? It uses strcoll(3) by default, which ignores the locale and does what strcmp(3) does, or strcasecmp(3) with -f, which ignores the locale too. So remove the setlocale(3), remove the header, the LC_ that have been commented out since the initial revision in 1995,

LC_TIME in calendar(1)

calendar imho doesn't need to setlocale(LC_TIME, ...) before and after strftime(3), as LC_TIME is ignored. Jan Index: day.c === RCS file: /cvs/src/usr.bin/calendar/day.c,v retrieving revision 1.34 diff -u -p -r1.34 day.c ---

Re: Implement Event()/Signal()/Wait() AML operations

> From: "Theo de Raadt" > Date: Thu, 10 Jan 2019 10:23:27 -0700 > > Ted Unangst wrote: > > > Ted Unangst wrote: > > > > > > Does 0x come from ACPI? Can we give that a name? > > > > > > I thought sleeping for one tick is kinda weird, but I see what > > > it's doing with the acpi_dotask loo

Re: Implement Event()/Signal()/Wait() AML operations

> From: "Ted Unangst" > Date: Wed, 09 Jan 2019 19:01:09 -0500 > > Mark Kettenis wrote: > > Index: dev/acpi/dsdt.c > > === > > RCS file: /cvs/src/sys/dev/acpi/dsdt.c,v > > retrieving revision 1.243 > > diff -u -p -r1.243 dsdt.c > > --

Re: Add virtio 1.0 pci ids

On Thu, Jan 10, 2019 at 06:59:15PM +0100, Stefan Fritsch wrote: > Everything above 0x1040 is 1.x only. > > Also tweak descriptoin of memory balloon device. There will be a memory, > too. > > OK? > ok > diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs > index 14943bb1350..72f95a29b00

Add virtio 1.0 pci ids

Everything above 0x1040 is 1.x only. Also tweak descriptoin of memory balloon device. There will be a memory, too. OK? diff --git a/sys/dev/pci/pcidevs b/sys/dev/pci/pcidevs index 14943bb1350..72f95a29b00 100644 --- a/sys/dev/pci/pcidevs +++ b/sys/dev/pci/pcidevs @@ -6692,12 +6692,17 @@ pro

Re: LC_NUMERIC in wprintf(3)

On Jan 10 14:43:39, h...@stare.cz wrote: > The wprintf(3) manpage says > > The decimal point character is defined > in the program's locale (category LC_NUMERIC) > > but LC_NUMERIC is ignored in OpenBSD's C library, > as explained in setlocale(3). > > Would it be an improvement to re

Re: Implement Event()/Signal()/Wait() AML operations

Ted Unangst wrote: > Ted Unangst wrote: > > > > Does 0x come from ACPI? Can we give that a name? > > > > I thought sleeping for one tick is kinda weird, but I see what it's doing > > with > > the acpi_dotask loop. This feels precarious, but whatever. > > So upon further thought, this is p

Re: sleep(1): support longer naps (redux)

On Thu, Jan 10 2019, Scott Cheloha wrote: > Now that we have removed the 100 million second upper bound we can > remove this awful loop. > > Effectively a revert of sleep.c 1.25. > > ok? ok -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE

sleep(1): support longer naps (redux)

Now that we have removed the 100 million second upper bound we can remove this awful loop. Effectively a revert of sleep.c 1.25. ok? Index: sleep.c === RCS file: /cvs/src/bin/sleep/sleep.c,v retrieving revision 1.26 diff -u -p -r1.2

Re: LC_NUMERIC in wprintf(3)

Hi Jan, Jan Stary wrote on Thu, Jan 10, 2019 at 02:43:39PM +0100: > The wprintf(3) manpage says > > The decimal point character is defined > in the program's locale (category LC_NUMERIC) > > but LC_NUMERIC is ignored in OpenBSD's C library, > as explained in setlocale(3). Right, i

Re: trunk shouldnt care if it's stacked

On 09/01/19(Wed) 19:12, Theo de Raadt wrote: > Philip Guenther wrote: > > > On Wed, Jan 9, 2019 at 1:11 AM Klemens Nanni wrote: > > > > > On Wed, Jan 09, 2019 at 01:12:31PM +1000, David Gwynne wrote: > > > > -#define TRUNK_MAX_STACKING 4 /* maximum number of stacked > > > trunks */ > >

LC_NUMERIC in wprintf(3)

The wprintf(3) manpage says The decimal point character is defined in the program's locale (category LC_NUMERIC) but LC_NUMERIC is ignored in OpenBSD's C library, as explained in setlocale(3). Would it be an improvement to remove that sentence? (Removing a needless newline while