Re: CVS commit: src/lib/libc/ssp

2023-11-15 Thread Christos Zoulas
On 2023-11-14 10:31 pm, Jörg Sonnenberger wrote: On Wednesday, November 15, 2023 4:15:28 AM CET you wrote: The functions are supposed to be transparent and they used to be. Can we please just go back to the working state before? IMO wanting to overriding getcwd is absolutely no justification

Re: bin/57544: sed(1) and regex(3) problem with encoding

2023-09-05 Thread Christos Zoulas
In article , RVP wrote: >On Wed, 30 Aug 2023, Christos Zoulas wrote: > >> Why don't we make next and end unsigned char so that all instances are fixed? >> > >:) My original attempt did just that, but then I had to cast to char in a lot >more places to get l

Re: bin/57544: sed(1) and regex(3) problem with encoding

2023-08-30 Thread Christos Zoulas
In article , wrote: >On Wed, Aug 30, 2023 at 02:32:25PM -0000, Christos Zoulas wrote: >> In article , >> RVP wrote: >> >On Wed, 26 Jul 2023, tlaro...@polynum.com wrote: >> > >> >> $ export LC_CTYPE=fr_FR.ISO8859-15 >> >> >> >&g

Re: bin/57544: sed(1) and regex(3) problem with encoding

2023-08-30 Thread Christos Zoulas
In article , RVP wrote: >On Wed, 26 Jul 2023, tlaro...@polynum.com wrote: > >> $ export LC_CTYPE=fr_FR.ISO8859-15 >> >> and then: >> >> $ echo "??" | sed 's/??\/g' >> sed: 1: "s/??\/g": RE error: trailing backslash (\) >> > >Not running NetBSD right now, but, FreeBSD 13.2 has the same issue

Re: epoll exposure

2023-08-12 Thread Christos Zoulas
implementation is broken in a way that will affect applications). Best, christos > On Aug 12, 2023, at 6:58 PM, Greg Troxel wrote: > > nia writes: > >> On Fri, Aug 11, 2023 at 06:52:41PM -0000, Christos Zoulas wrote: >>> I see that you removed with witho

Re: epoll exposure

2023-08-11 Thread Christos Zoulas
> On Aug 11, 2023, at 3:09 PM, Tobias Nygren wrote: > > On Fri, 11 Aug 2023 18:52:41 - (UTC) > chris...@astron.com (Christos Zoulas) wrote: > >> In article , >> nia wrote: >>> On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote: >>&g

Re: epoll exposure

2023-08-11 Thread Christos Zoulas
In article , nia wrote: >On Mon, Jul 31, 2023 at 07:18:38PM -0700, Jason Thorpe wrote: >> Anyway, like I said, I think the best way forward is to make it >possible for kq descriptors to be inherited… it’s a little tricky >because of some of the wacky stuff kqueue can track, but I think

Re: style, sysexits(3), and man RETURN VALUES for sys programs

2023-07-04 Thread Christos Zoulas
In article , wrote: >Le Sat, Jul 01, 2023 at 06:39:32PM -0000, Christos Zoulas a écrit : >> In article <20230603120221.0766b60...@jupiter.mumble.net>, >> Taylor R Campbell wrote: >> >> Date: Sat, 3 Jun 2023 13:45:44 +0200 >> >> From: tlaro...

Re: style, sysexits(3), and man RETURN VALUES for sys programs

2023-07-01 Thread Christos Zoulas
In article <20230603120221.0766b60...@jupiter.mumble.net>, Taylor R Campbell wrote: >> Date: Sat, 3 Jun 2023 13:45:44 +0200 >> From: tlaro...@polynum.com >> >> So I suggest to add a mention of sysexits(7) to style. > >I don't think sysexits(7) is consistently used enough, or really >useful

Re: dynamic linker change to handle multiple PT_LOAD segments

2023-01-05 Thread Christos Zoulas
In article <3cf2e88d-1262-419d-bfcf-c11599e2b...@me.com>, Jason Thorpe wrote: > >> On Jan 5, 2023, at 8:53 AM, Christos Zoulas wrote: >> >> Hello, >> >> Our dynamic linker ld_elf.so in map_object.c currently can only handle >2 PT_LOAD segments (one

dynamic linker change to handle multiple PT_LOAD segments

2023-01-05 Thread Christos Zoulas
Hello, Our dynamic linker ld_elf.so in map_object.c currently can only handle 2 PT_LOAD segments (one for text and one for data); the kernel elf loader does not have this limitation, it can load multiple PT_LOAD segment. The following patch (from FreeBSD) removes this limitation from the

Re: regex change

2022-11-10 Thread Christos Zoulas
In article , enh wrote: >-=-=-=-=-=- > >ah, thanks for that link. stupidly, although i'd seen that the NetBSD >changes were syncing with FreeBSD, i didn't go to look at the original >FreeBSD commits. > >cool, that sounds like i (a) have a clear "why" argument should anyone ask, >and (b) a

Re: regex change

2022-11-10 Thread Christos Zoulas
In article , enh wrote: >-=-=-=-=-=- > >i see (having synced the current NetBSD lib/libc/regex to Android) that >regcomp() no longer allows unescaped `{` and `}`. this is technically >correct (since POSIX explicitly calls this undefined behavior), but it's a >change from historical NetBSD

Re: [Christos Zoulas] CVS commit: src/usr.bin/ftp

2022-09-02 Thread Christos Zoulas
> On Sep 2, 2022, at 3:57 PM, Greg Troxel wrote: > > Did I miss discussion on this? I am getting the impression that we now > have defaults: > no trust anchors installed > require verification > > which really doesn't make sense. If I am following correctly this is a > major behavior

Re: -DFANCY in robots(6)

2022-06-26 Thread Christos Zoulas
In article , Charlotte Koch wrote: >Hiya, > >My inclination is to remove all code from robots(6) that is guarded >inside "#ifdef FANCY" -- because it isn't defined at all in the code nor >the Makefile. And "FANCY" doesn't seem to have any meaning in e.g. >curses, either. > >That led me to

Re: Interested in working on NetBSD project

2022-05-26 Thread Christos Zoulas
On 2022-05-23 3:45 am, ga...@iitk.ac.in wrote: Dear Christos, I am Gagan Aryan, a senior year computer science undergraduate at IIT Kanpur, India. I came across this project - Research and integrate the static code analysers with the NetBSD codebase on the NetBSD site. I am interested in

Re: to bump or note to bump

2022-04-06 Thread Christos Zoulas
In article , Brett Lymn wrote: > >Folks, > >This started out innocuously enough, I picked up a PR about fileobj from >pkgsrc not working properly. This was partially an upstream problem but >also an issue with our curses chgat() function. After a bit of digging >I found two things.

Re: lib/libcrypt/crypt-argon2.c: ctx.{out,outlen} assigned twice

2022-02-13 Thread Christos Zoulas
In article , RVP wrote: >Looks like ctx.{out,outlen} are being assigned twice: > >---START--- >--- lib/libcrypt/crypt-argon2.c.orig 2021-11-22 21:56:12.532724453 + >+++ lib/libcrypt/crypt-argon2.c2022-02-11 09:59:51.260664174 + >@@ -386,9 +386,6 @@ > > /* we use static

Re: brandelf(1)

2022-01-18 Thread Christos Zoulas
In article <20220117123329.ga19...@mail.duskware.de>, Martin Husemann wrote: >On Mon, Jan 17, 2022 at 12:28:51PM +0100, Manuel Bouyer wrote: >> Hello, >> so, to be able to run linux binaries with don't have the Linux type >> in its ELF header, I have ported FreeBSD's brandelf(1): >>

Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.

2021-10-26 Thread Christos Zoulas
In article <141d1bec-0f6d-4bb8-8b44-aba98806c...@me.com>, Jason Thorpe wrote: > >> On Oct 26, 2021, at 6:56 AM, Jason Thorpe wrote: >> >> Obviously, the practical impact of this is nil, since no one apparently >noticed (and I guess we didn’t break any programs that people were >using). We

Re: openssl 3

2021-09-30 Thread Christos Zoulas
In article , Greg Troxel wrote: >-=-=-=-=-=- > > >This is a software engineering question, not a security question and >hence here. > >openssl 3.0.0 is out, and it has a lot of compat issues. >I hear that openssl 1.1.1 only has two years of maintenance left. > >history: 8 was released in July

Re: libxh509 vs ftpd vs sun2

2021-06-20 Thread Christos Zoulas
In article <29706.1624176...@splode.eterna.com.au>, matthew green wrote: >hi folks. > > >enabling gcc10 on sun2 triggered a build failure that i didn't >see locally with MKPAM=no builds. the problem is that libhx509 >and ftpd both defined yyval and yyerrflag, and the -fno-common >default makes

Re: Q about pthread condition variable usage - mixing interlocks

2021-04-08 Thread Christos Zoulas
In article <63f5d53a-2767-48f2-b7fa-fbfe93f63...@me.com>, Jason Thorpe wrote: >As far as I can tell, POSIX has no language that covers this situation, >so I’m tossing it out here for the hive mind... > >Is there ANY situation where, for a given pthread condition variable, >that using a

Re: CVS commit: src/share/misc

2021-03-30 Thread Christos Zoulas
In article <6734.1617154...@splode.eterna.com.au>, matthew green wrote: >Christos Zoulas writes: >> In article <20900.1616977...@splode.eterna.com.au>, >> matthew green wrote: >> >> Log Message: >> >> Clarify and explain the rationale for

Re: patch: Option to not create backup files creates backup files

2021-02-19 Thread Christos Zoulas
In article , nia wrote: >I noticed some odd behaviour when I tried to use patch(1) without >creating backup files (-V none). It seems this option is ignored, >and backup files are created anyway. The PATCH_VERSION_CONTROL >environment variable can also override -V none, which is the >opposite of

Re: master.passwd(5) questions

2021-01-16 Thread Christos Zoulas
In article , Hauke Fath wrote: >Hi, > >I am looking at augmenting the linux-style 'shadow' map generation in >/var/yp/Makefile.yp. > >In this context: > >(1) The 'change' field in master.passwd can either be empty[*] (no >passwd aging), hold a maximum passwd age, or hold '-1', forcing the user

Re: tolower()/islower() and char

2021-01-14 Thread Christos Zoulas
In article <20210114111428.ga1...@antioche.eu.org>, Manuel Bouyer wrote: >Hello, >In xentools, we have patches like >-if (tolower(*s) != tolower(*se)) >+if (tolower((unsigned char)*s) != tolower((unsigned char)*se)) > >(s and se being char*) > >This is to fix «array

Re: inetd Enhancements Followup

2020-11-29 Thread Christos Zoulas
In article , Greg Troxel wrote: >-=-=-=-=-=- > > >James Browning writes: > >> maintainers at their own discretion. Some of you brought up the concern of >> over-automating the system at the potential risk of the configuration system >> becoming too opaque and administrators allowing packages to

Re: enabling ldap for racoon ?

2020-11-29 Thread Christos Zoulas
In article <20201125181734.ge1...@antioche.eu.org>, Manuel Bouyer wrote: >-=-=-=-=-=- > >Hello >I did spend some time to improve the ldap support in racoon(8). >It's now working fine for me. >Would anyone object enabling ldap support by default ? >See attached patch Go for it. christos

Re: Drop .me from man.conf(5)

2020-11-21 Thread Christos Zoulas
In article <702ebe22-e2c6-3c5f-a86b-b9eb184b1...@netbsd.org>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >I propose to drop .me from man.conf(5): > >http://netbsd.org/~kamil/patch-00288-drop-me-from-man.conf.txt > >There is no evidence that it has any users and unclear whether there

Re: Proposal to import window(1) into the base

2020-10-24 Thread Christos Zoulas
In article , Valery Ushakov wrote: >Alistair Crooks wrote: > >> If it comes back, it needs to be modified to use curses - the hardcoded >> terminal escapes for a bunch of 1970s terminals is kinda cute in a retro >> way; it's also kinda embarassing. > >From a very quick look half of window

Re: recent changes to pthread_fork.c:fork() cause static linking to fail if the app provides its own malloc()

2020-07-16 Thread Christos Zoulas
In article , Greg A. Woods wrote: >-=-=-=-=-=- > >At Tue, 14 Jul 2020 20:05:57 - (UTC), chris...@astron.com (Christos >Zoulas) wrote: >Subject: Re: recent changes to pthread_fork.c:fork() cause static >linking to fail if the app provides its own malloc() >> >>

Re: [chris...@netbsd.org: CVS import: src/external/mit/libuv/dist]

2020-05-30 Thread Christos Zoulas
In article <20200528203553.gb12...@bec.de>, Joerg Sonnenberger wrote: >On Thu, May 28, 2020 at 06:04:23PM -, Christos Zoulas wrote: >> In article <20200527141158.ga16...@bec.de>, >> Joerg Sonnenberger wrote: >> >----- Forwarded message from Christos Zoul

Re: [chris...@netbsd.org: CVS import: src/external/mit/libuv/dist]

2020-05-28 Thread Christos Zoulas
In article <20200527141158.ga16...@bec.de>, Joerg Sonnenberger wrote: >- Forwarded message from Christos Zoulas - > >Date: Sun, 24 May 2020 15:26:41 -0400 >From: Christos Zoulas >To: source-chan...@netbsd.org >Subject: CVS import: src/external/mit/libuv/dist

Re: Pass -fno-delete-null-pointer-checks to Clang under MKSANITIZER/MKLIBCSANITIZER

2020-05-23 Thread Christos Zoulas
In article , Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 13.05.2020 19:07, Kamil Rytarowski wrote: >> I propose to pass -fno-delete-null-pointer-checks to Clang under >> MKSANITIZER/MKLIBCSANITIZER. >> >> http://netbsd.org/~kamil/patch-00251-rump-fno-delete-null-pointer-checks.txt

Re: PATCH libatomic

2020-05-10 Thread Christos Zoulas
In article <9d775d79-026a-f52a-ae3c-39a00eea4...@gmx.com>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 08.05.2020 21:33, m...@netbsd.org wrote: >> On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote: >>> I object to opinions that libatomic is generally broken, if that

Re: PATCH libatomic

2020-05-09 Thread Christos Zoulas
In article <20200509045010.gb4...@mail.duskware.de>, Martin Husemann wrote: >On Fri, May 08, 2020 at 10:24:43PM +, m...@netbsd.org wrote: >> The indirection only applies to the first call. The magic is within >> rtld. > >You are comparing PLT calls with ifunc (where even normal PLT calls

Re: __hldtoa broken for ld128

2020-04-11 Thread Christos Zoulas
In article , enh wrote: >this was found by fuzzing the LLVM __cxa_demangle on an ld128 Android >system using hwasan, but it turns out no to simply be a buffer >overflow --- the results are just wrong. (which shows how much anyone >uses ld128 in conjunction with %a!) Thanks a lot for the heads

Re: recent terminfo changes

2020-03-30 Thread Christos Zoulas
> On Mar 30, 2020, at 12:03 AM, Roy Marples wrote: > > On 30/03/2020 04:05, Christos Zoulas wrote: >>> On Mar 29, 2020, at 10:37 PM, Roy Marples wrote: >>> >>> blacklistd was not working for me and the ACL check you mention was >>> certainl

Re: recent terminfo changes

2020-03-29 Thread Christos Zoulas
> On Mar 29, 2020, at 10:37 PM, Roy Marples wrote: > > blacklistd was not working for me and the ACL check you mention was certainly > not described anywhere I saw. After reading the Fine Man Page, I came to the > conclusion that passing a sockaddr with a fd of -1 was expected to work with

Re: recent terminfo changes

2020-03-29 Thread Christos Zoulas
les wrote: > > On 30/03/2020 02:19, Christos Zoulas wrote: >> Recently you changed blacklistd without prior discussion and >> you introduced a security bug. The terminfo2 changes were not discussed >> either - I would have objected to creating yet another file to hold

Re: recent terminfo changes

2020-03-29 Thread Christos Zoulas
> On Mar 29, 2020, at 9:42 PM, Roy Marples wrote: > > On 30/03/2020 02:19, Christos Zoulas wrote: >> The terminfo database before I cleaned it up was a mess. There was >> no build process, or explanation how to import it, or what the local >> changes where. > &

Re: recent terminfo changes

2020-03-29 Thread Christos Zoulas
I did not plan to work on this in the first place, and I presented a better solution to provide compatibility. Nobody jumped on it, and I felt that I had to jump in and implement it before terminfo2 was cast in stone. The terminfo database before I cleaned it up was a mess. There was no build

Re: recent terminfo changes

2020-03-27 Thread Christos Zoulas
In article <431d1631-ef82-d1ec-98ff-e39b71418...@marples.name>, Roy Marples wrote: >On 27/03/2020 13:15, Christos Zoulas wrote: >> >> >>> On Mar 27, 2020, at 4:05 AM, Roy Marples wrote: >>> >>> On 27/03/2020 02:06, Christos Zoulas wrote:

Re: recent terminfo changes

2020-03-27 Thread Christos Zoulas
> On Mar 27, 2020, at 4:05 AM, Roy Marples wrote: > > On 27/03/2020 02:06, Christos Zoulas wrote: >> @@ -494,6 +530,7 @@ >> if (tic == NULL) >> return NULL; >> + tic->rtype = _ti_find_rtype(cap); >> buf.buf = NULL; &

Re: recent terminfo changes

2020-03-26 Thread Christos Zoulas
In article , Christos Zoulas wrote: >In article <20200324144303.e147610...@quasar.astron.com>, >Christos Zoulas wrote: Finally here is a complete patch that deletes terminfo2.cdb. This patch restores compatibility with the old terminfo format for most entries except the handful on

Re: recent terminfo changes

2020-03-26 Thread Christos Zoulas
In article <20200324144303.e147610...@quasar.astron.com>, Christos Zoulas wrote: >Hello, > >The recent terminfo ABI change to widen numeric constants from 16 bits to >32 bits was done in the following way: > >1. Create a new terminfo2 database and rely on the fact that o

recent terminfo changes

2020-03-24 Thread Christos Zoulas
Hello, The recent terminfo ABI change to widen numeric constants from 16 bits to 32 bits was done in the following way: 1. Create a new terminfo2 database and rely on the fact that old programs will use the old filename and new ones will use the new filename. 2. Add compatibility code so

Re: blacklisting nodes that probe non-existant nodes

2020-03-13 Thread Christos Zoulas
In article , Christos Zoulas wrote: >-=-=-=-=-=- > > >> >> Anyone can open PF_ROUTE and read from it or write RTM_GET. >> However, you need to have it opened as root to write any other operations. >> Do we have a means of testing that without writing to the soc

Re: blacklisting nodes that probe non-existant nodes

2020-03-12 Thread Christos Zoulas
> > Anyone can open PF_ROUTE and read from it or write RTM_GET. > However, you need to have it opened as root to write any other operations. > Do we have a means of testing that without writing to the socket? > I'm guessing no. > > I suppose we could enforce testing if SCM_CREDENTIALS passed

Re: blacklisting nodes that probe non-existant nodes

2020-03-11 Thread Christos Zoulas
In article <6d301f35-05ea-25b4-fb19-c473d68fd...@marples.name>, Roy Marples wrote: >-=-=-=-=-=- > >Hi > >So I have an IPv6 capable interface on my router. >When I run route monitor, I get a lot of RTM_MISS for non-existant nodes on my >prefix. Logging this to the ERLITE takes a fair chunk of

Re: Expose max_align_t unconditionally

2020-03-10 Thread Christos Zoulas
inition. > > I don't understand what we try fix here and what is broken (what fails > to build, what is misbehaving) after exposing max_align_t. > > On 10.03.2020 12:38, Christos Zoulas wrote: >> I've been following this discussion and it seems that: >> >> 1. upstr

Re: Expose max_align_t unconditionally

2020-03-10 Thread Christos Zoulas
I've been following this discussion and it seems that: 1. upstream is not interested making the library support < c++11 2. finding the correct "max_align_t" is not obvious, but the library wants to 3. "max_align_t" should not be exposed to < c++11 Given the above constraints, the simplest

Re: Expose max_align_t unconditionally

2020-03-09 Thread Christos Zoulas
We gotta obey the namespace; perhaps use __max_align_t in the headers and only expose the real typedef for c++ > 98 or whatever. christos > On Mar 9, 2020, at 5:44 PM, Kamil Rytarowski wrote: > > On 09.03.2020 20:05, Martin Husemann wrote: >> This is pretty stupid, but IMHO no big deal. We

Re: Possibly out of sync/broken openssl code

2020-02-16 Thread Christos Zoulas
Thanks! Next time I import, I will try to minimize the diffs. I have been upstreaming a lot of our patches to different things lately and it requires patience and baby-sitting. christos > On Feb 16, 2020, at 7:10 AM, nisarg joshi wrote: > > signature.asc Description: Message signed with

Re: Possibly out of sync/broken openssl code

2020-02-15 Thread Christos Zoulas
Yes, because "unsigned long" on _LP64 is not 32bits. What is the undefined behavior you are trying to fix? christos > On Feb 15, 2020, at 7:03 PM, nisarg joshi wrote: > > Hi community, > > > > While trying to fix UBSan Undefined behavior reports for md4_dgst.c and > rmd_dgst.c files which

Re: [patch] pthread(3) + malloc(3) init model

2020-02-15 Thread Christos Zoulas
Looks clean to me. If it works, let's try it. We can always put it back. christos > On Feb 15, 2020, at 8:00 AM, Kamil Rytarowski wrote: > > Signed PGP part > I propose to separate the pthread_atfork(3) call from pthread_tsd_init() > and move it into a distinct function. > > I propose to call

Re: pam_krb5.c - -Werror=format-overflow

2020-02-07 Thread Christos Zoulas
In article , Santhosh Raju wrote: >-=-=-=-=-=- > >Hello > >While working with kamil@ on MKLIBCSANITIZER based build, I came >across a compile error in pam_krb5.c > >--- dependall-pam_krb5 --- >/home/fox/projects/netbsd/obj-wip/destdir.amd64/usr/include/security/pam_modules.h: >In function

Re: Solving the syslogd problem

2020-01-29 Thread Christos Zoulas
In article , David Brownlee wrote: >On Tue, 28 Jan 2020 at 21:21, Roy Marples wrote: >> >> syslogd is a powerful syslog implementation. >> It supports authenticated and encrypted TLS connections and signing messages. >> Because of this it lives in /usr due to the libraries it needs. >> /usr

Re: Proposal: Remove filemon(4); switch make meta to ktrace

2020-01-12 Thread Christos Zoulas
In article <20200112210449.accca60...@jupiter.mumble.net>, Taylor R Campbell wrote: >-=-=-=-=-=- > >[followups on tech-kern] > >I propose to remove the filemon(4) device. > >- Why? filemon(4), which writes records of file-related system calls > to a file, is redundant with ktrace, except

Re: libarchive patches

2019-12-30 Thread Christos Zoulas
In article <8dc6ce3d-5d37-db07-4fe6-accf7948b...@gmx.com>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- >Can we sync incompatible command line arguments, at least for sysinst? > >https://nxr.netbsd.org/xref/src/usr.sbin/sysinst/defs.h#511 511 #ifdef USING_PAXASTAR 512 #define

libarchive patches

2019-12-30 Thread Christos Zoulas
Hello, As promised, I've submitted two pull requests for upstream libarchive. I submitted the second one just today because I was waiting for almost a month to hear feedback for the first one, and now I've given up waiting. Here they are: https://github.com/libarchive/libarchive/pull/1289

Re: [patch] usbdevs(8) use strtol(3) instead of atoi(3) for more predictable result

2019-11-27 Thread Christos Zoulas
In article <20191125185148.GA2051@localhost.localdomain>, Alexander Kuleshov wrote: >On 11-25-19, Christos Zoulas wrote: >> You don't need "ep", you can pass NULL. >> > >The updated diff: Committed, christos

Re: [patch] usbdevs(8) use strtol(3) instead of atoi(3) for more predictable result

2019-11-25 Thread Christos Zoulas
In article <20191124191258.GA3086@localhost.localdomain>, 'Alexander Kuleshov' wrote: >Hello, > >On 11-24-19, Terry Moore wrote: >> >> Zero is never a legal address for an operating USB device. (It can >appear transiently during enumeration, but there's no way to operate a >device in that

Re: wedge device to name

2019-09-22 Thread Christos Zoulas
On Sep 22, 5:58pm, n...@gmx.com (Kamil Rytarowski) wrote: -- Subject: Re: wedge device to name | I understand and I know. Unfortunately (or fortunately) we will need to | live with the old syscall forever. Yes, but cleaning the old code is obvious and simple. Untangling the sysctl-augmented API

Re: wedge device to name

2019-09-22 Thread Christos Zoulas
019, at 10:55 AM, Kamil Rytarowski wrote: > > Signed PGP part > On 22.09.2019 15:39, Christos Zoulas wrote: >> In article , >> Christos Zoulas wrote: >>> In article , >>> Michael van Elst wrote: >>>> chris...@astron.com (Christos Zoulas) writes: >

Re: wedge device to name

2019-09-22 Thread Christos Zoulas
In article , Christos Zoulas wrote: >In article , >Michael van Elst wrote: >>chris...@astron.com (Christos Zoulas) writes: >> >>>I added that to df, but it needs root/operator in order to access the >>>device node to get wedge info. I also wrote a patch to

Re: wedge device to name

2019-09-19 Thread Christos Zoulas
In article , Michael van Elst wrote: >chris...@astron.com (Christos Zoulas) writes: > >>I added that to df, but it needs root/operator in order to access the >>device node to get wedge info. I also wrote a patch to expose the >>wedge info via sysctl: > >Alternativ

Re: wedge device to name

2019-09-18 Thread Christos Zoulas
In article , Michael van Elst wrote: >m...@netbsd.org (Emmanuel Dreyfus) writes: > >>But since almost all commands do the NAME=label to /dev/device translation, >>you can take NAME=label as a device path. > >Only some NetBSD commands do. Most are old-fashioned and want file paths >to deal with,

Re: Leak Sanitizer - how to suppress leaks

2019-09-13 Thread Christos Zoulas
In article <20190913072314.ga16...@mail.duskware.de>, Martin Husemann wrote: >On Fri, Sep 13, 2019 at 08:33:31AM +0200, Thomas Klausner wrote: >> I'm sorry, I totally do not get it the problem with -- in general -- >> writing the code in such a way that it properly frees any allocations >> it

Re: Fwd: Change in aosp/bionic[master]: [fuzzers] Test for ns_parserr() and got a heap-buffer-overflow.

2019-09-04 Thread Christos Zoulas
In article , enh wrote: >FYI, https://android-review.googlesource.com/c/platform/bionic/+/1093130 >fixes a bug recently found by fuzzing the DNS code we share with >NetBSD. Fixed thanks! christos

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
> The original problem is udata of intptr_t insted of void* (like in > FreeBSD) and with C++ compilers it's not possible to cast it cleanly to > intptr_t without alternative approaches. > > This keeps breaking C++ users and we need to patch 3rd party code from > the caller level. > > It used

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
pp:7:32: warning: use of old-style cast [-Wold-style-cast] printf("%jd", (intptr_t)argv[0]); ^ > On Aug 11, 2019, at 8:24 PM, Kamil Rytarowski wrote: > > On 11.08.2019 19:22, Christos Zoulas wrote: >> Ok, with what version of event.h, th

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
Ok, with what version of event.h, the template specialization? I don't see how it is possible to not warn for (cast)foo christos

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
Did you use -Wold-style-cast? We've come full circle now, and what we have seems to be more complicated than what we had before and I am not sure what was the problem in the first place... Can we just step back and understand what is the problem we are trying to solve with all this complexity?

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
Now you get warnings with -Wold-style-cast (which is the reason for __CAST() in the first place). christos

Re: EV_SET() better C++ compat with alternative implementations

2019-08-11 Thread Christos Zoulas
In article <3ebcc5d1-a57d-a290-72d8-6efc73025...@gmx.com>, Kamil Rytarowski wrote: >-=-=-=-=-=- >-=-=-=-=-=- > >On 11.08.2019 02:56, Valery Ushakov wrote: >> Kamil Rytarowski wrote: >> >>> Cast of udata from void* to intptr_t shall be done with >>> reinterpret_cast<> otherwise a C++ compiler

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
If we make Kamil's suggested ", ...) __printflike" change, then upstream will not have to #ifdef __NetBSD__ the calls. christos > On Aug 9, 2019, at 9:11 PM, Martin Husemann wrote: > > On Fri, Aug 09, 2019 at 07:09:01PM +0200, Kamil Rytarowski wrote: >> Delayed adoption of a standardized

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
to adopt the printflike setname_np() (I don't), let's go for it. christos > On Aug 9, 2019, at 7:11 PM, Kamil Rytarowski wrote: > > On 09.08.2019 17:47, Christos Zoulas wrote: >> I understand that I am using contrived examples. I am just pointing out that >> we don't >

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
ly instead of adding a most excellent band-aid. christos > On Aug 9, 2019, at 6:39 PM, Kamil Rytarowski wrote: > > On 09.08.2019 17:34, Christos Zoulas wrote: >> I think we should stop playing games and provide a completely compatible api. >> If we want enhanced API'

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
tBSD and 2 everywhere else? What are you going to do then? christos > On Aug 9, 2019, at 5:06 PM, Kamil Rytarowski wrote: > > On 09.08.2019 16:03, Martin Husemann wrote: >> On Fri, Aug 09, 2019 at 04:00:02PM +0200, Kamil Rytarowski wrote: >>> On 09.08.2019 15:32, Ch

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
My worry is that someone will call pthread_setname_np() with a "%thread%s" name argument and get a core dump on a NetBSD system since the string will be interpreted as a format (where in other OS's it will be taken literally and work. christos > On Aug 9, 2019, at 4:12 PM, Kamil Rytarowski

Re: pthread_setname_np API is bad

2019-08-09 Thread Christos Zoulas
In article , Matt Turner wrote: >On Tue, Aug 6, 2019 at 7:17 AM Kamil Rytarowski wrote: >> >> On 06.08.2019 07:19, Matt Turner wrote: >> > On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon wrote: >> >> >> >> On Fri, Aug 02, 2019 at 09:29:27PM -0700, Matt Turner wrote: >> >>> >> >>> So great,

Re: jemalloc config

2019-06-30 Thread Christos Zoulas
In article , Robert Swindells wrote: > >The man page for jemalloc suggests that you should only enable filling >memory with junk values on malloc and free when debugging as it will >impact performance. > >We seem to have it enabled by default, is that intentional ? Yes, because we found a lot

Re: [PATCH] grep: fix ASan heap-buffer-overflow.

2019-04-05 Thread Christos Zoulas
In article , enh wrote: >-=-=-=-=-=- > >here's a patch that doesn't actually break anything. the previous >version was wrong in the non-copy case, so this version always copies. >(the alternative would be to remember the overwritten byte and restore >it on the next call, but this brings the code

Re: namespace pollution by curses

2019-03-12 Thread Christos Zoulas
In article <20190312134722.ga1...@netbsd.org>, David Holland wrote: >On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote: > > Admittedly, I'm not sure about the usage. E.g. in wscons case you can > > press a modifier on one keyboard and the key on another and it should > > work. But

Re: namespace pollution by curses

2019-03-08 Thread Christos Zoulas
In article <20190308135342.ga17...@mail.duskware.de>, Martin Husemann wrote: >On Fri, Mar 08, 2019 at 10:41:51PM +0900, Rin Okuyama wrote: > >> I've found that this is because curses uses a global variable "state": >> https://nxr.netbsd.org/xref/src/lib/libcurses/getch.c#50 >>

Re: cgdconfig verification method failure

2019-02-21 Thread Christos Zoulas
In article <732e3468-143f-c154-70b6-f0d57b864...@eq.cz>, rudolf wrote: >-=-=-=-=-=- > >rudolf wrote: >> (observed under netbsd-8, attached is an untested (but trivial) patch >> for current) > >Attached is a tested and corrected version of the patch (differences to >previous: 1. missing

Re: colorls in base

2019-02-17 Thread Christos Zoulas
> On Feb 17, 2019, at 4:49 PM, John Nemeth wrote: > > On Feb 17, 10:33am, Christos Zoulas wrote: > } On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote: > } | On 2/17/19 5:52 AM, John Nemeth wrote: > } | > } We resist also personal taste but aesthet

Re: colorls in base

2019-02-17 Thread Christos Zoulas
On Feb 17, 11:45am, ch...@groessler.org (Christian Groessler) wrote: -- Subject: Re: colorls in base | On 2/17/19 5:52 AM, John Nemeth wrote: | > } We resist also personal taste but aesthetics is also important for | > } many/most(?) people. For the some reason probably nobody deliberately | > }

Re: colorls in base

2019-02-16 Thread Christos Zoulas
> On Feb 16, 2019, at 12:30 PM, Hauke Fath > wrote: > > I remember you speaking up against replacing csh(1) with tcsh in base a few > years ago. How about adding tcsh's complete facility to csh(1)? That is > probably an order of magnitude in codesize compared to ls(1) vs. > colo(u)rls, but I

Re: colorls in base

2019-02-16 Thread Christos Zoulas
In article <20190216102435.ga10...@grapefruit.pr0.tips>, Timo Buhrmester wrote: >> All I know is that some directories look like an "explosion in a >> paint factory" or "angry fruit salad". >I wonder why the die-hard monochrome users keep arguing from a >"but it isn't pretty" point of view.

Re: colorls in base

2019-02-15 Thread Christos Zoulas
In article , Hauke Fath wrote: >At 11:46 Uhr -0500 15.02.2019, Christos Zoulas wrote: >>| Please read it again - that is not what Rin said. In fact, he gave >>| technical reasons. >> >>I am not happy with the interaction, not the decision. > >That's fine. I ca

Re: colorls in base

2019-02-15 Thread Christos Zoulas
On Feb 15, 4:40pm, ha...@espresso.rhein-neckar.de (Hauke Fath) wrote: -- Subject: Re: colorls in base | At 13:58 Uhr + 15.02.2019, Christos Zoulas wrote: | >In article <2e0ff950-5f64-c807-1fc3-2d4b9e10b...@gmail.com>, | >Rin Okuyama wrote: | >>OK, I withdraw the proposa

Re: colorls in base

2019-02-15 Thread Christos Zoulas
All this color discussion made me think: The kernel is already using green, and recently we added "autoconfiguration error" to highlight errors. Shouldn't we (in addition) make those lines red? Someone mentioned that the gnu-color-ls style is better. I *think* that tcsh does both (compatibly)

Re: colorls in base

2019-02-15 Thread Christos Zoulas
In article <2e0ff950-5f64-c807-1fc3-2d4b9e10b...@gmail.com>, Rin Okuyama wrote: >OK, I withdraw the proposal. > >Before pointed out by Kamil, I thought it useful to have compatible >with FreeBSD/OS X. But as he wrote, their style is disordered. > >If we redesign it, it would be something like

Re: colorls in base

2019-02-15 Thread Christos Zoulas
In article <20190215082158.gb...@antioche.eu.org>, Manuel Bouyer wrote: >On Thu, Feb 14, 2019 at 06:26:29PM -0800, John Nemeth wrote: >> On Feb 15, 10:56am, Rin Okuyama wrote: >> } >> } I'd like to propose to introduction -G (colorized output) option >> } to ls(1), which is compatible to

Re: colorls in base

2019-02-15 Thread Christos Zoulas
In article <201902150226.x1f2qt6r003...@server.cornerstoneservice.ca>, John Nemeth wrote: >On Feb 15, 10:56am, Rin Okuyama wrote: >} >} I'd like to propose to introduction -G (colorized output) option >} to ls(1), which is compatible to FreeBSD and macOS: >} >}

Re: missing regex fixes from FreeBSD/OpenBSD?

2019-02-07 Thread Christos Zoulas
In article , enh wrote: >this FreeBSD regex fix seems to apply to the NetBSD copy of the code too? > >https://github.com/freebsd/freebsd/commit/981dd2aa38f37e4d0dd86225c619e900fc03d82e#diff-d7c26714f9432399b202eefcedb97491 > >as does this one? >

Re: Lua shared object asymmetry loading Xlib.

2019-01-04 Thread Christos Zoulas
In article <20190104182924.gd23...@pony.stderr.spb.ru>, Valery Ushakov wrote: > >When atexit handlers are run when main returns the dlclose has already >yanked the function that was registered to run. With explicit >os.exit() the exit happens while the libs are still loaded, so it >works ok. I

  1   2   3   >