Cleanup of err(1, "unveil") pattern: xenocara

Ashton Fagg writes: > Hi all, > > I saw a discussion on here a while ago about the use of patterns like: > > if (unveil(some_path, "r") == -1) >err(1, "unveil"); > > And why that's maybe not preferable for debugging and troubleshooting > purposes for programs which have multiple unveil calls

Re: Cleanup of err(1, "unveil") pattern: bin, games, sbin

"Theo de Raadt" writes: > Showing the symbolic name is not doing anywhere else in the tree. > > Most likely they should be > > err(1, "unveil: %s", path); Per Theo's advice, updated diffs are attached. diff --git a/sbin/dhclient/dhclient.c b/sbin/dhclient/dhclient.c index 993c829f2d2..

Re: Cleanup of err(1, "unveil") pattern: bin, games, sbin

Thanks for the review - wasn't sure if that was useful. Will regenerate without the symbolic names. On Sun, 2 May 2021 at 20:37, Theo de Raadt wrote: > > Showing the symbolic name is not doing anywhere else in the tree. > > Most likely they should be > >err(1, "unveil: %s", path); > >

Re: Cleanup of err(1, "unveil") pattern: bin, games, sbin

Showing the symbolic name is not doing anywhere else in the tree. Most likely they should be err(1, "unveil: %s", path); Ashton Fagg wrote: > Ashton Fagg writes: > > > Hi all, > > > > I saw a discussion on here a while ago about the use of patterns like: > > > > if (unveil(some_p

Cleanup of err(1, "unveil") pattern: bin, games, sbin

Ashton Fagg writes: > Hi all, > > I saw a discussion on here a while ago about the use of patterns like: > > if (unveil(some_path, "r") == -1) >err(1, "unveil"); > > And why that's maybe not preferable for debugging and troubleshooting > purposes for programs which have multiple unveil calls

Fix compiler warning from sysctl.c

Fixes the following warning: sysctl.c:835:18: warning: format specifies type 'char *' but the argument has type 'void *' [-Wformat] string, newval); ^~ sysctl.c:840:18: warning: format specifies ty

Diff for www:OpenBSD/powerpc64

Hi, Here a diff for www page: OpenBSD/powerpc64 Hi. According to page 68, 6.8 was the first version for the platform. Right? Index: powerpc64.html === RCS file: /cvs/www/powerpc64.html,v retrieving revision 1.7 diff -u -r1.7 p

Re: diff for wireguard examples on faq17.html

I'll work a diff for wg(4). Thanks, Jim On Sun, May 02, 2021 at 09:57:33AM -0600, Theo de Raadt wrote: > If the manual page is weak, it should be improved. > > The FAQ cannot make up for it. The FAQ requires online interaction > and far fewer people read it. > >

Re: diff for wireguard examples on faq17.html

Sorry accidently replied directly to Theo instead of the list. Yes to both of your questions. Sorry if this is noise or spam. Section of manpage: EXAMPLES Create two wg interfaces in separate rdomain(4)s, which is of no practical use but demonstrates two interfaces on the same machine:

Diff for www:FAQ ports/ports

Hi, Here a diff for www page: FAQ ports/ports Hi, see this typo error on the page. Right? Index: faq/ports/ports.html === RCS file: /cvs/www/faq/ports/ports.html,v retrieving revision 1.57 diff -u -r1.57 ports.html --- faq/por

diff for wireguard examples on faq17.html

Hi, There has been a lot of interest in WireGuard on the OpenBSD subreddit. So here is a patch that provides a few basic examples for usage. Thanks, Jim Index: www/faq/faq17.html === RCS file: /cvs/www/faq/faq17.html,v retrieving r

Re: added support for precompressed static files on httpd(so sorry about my other email that was unreadable)

> your diff has numerous issues. What exactly do you mean by issues? Do you mean bugs? > It also seems you've either purposely broken comment blocks or > are commenting out sections of existing code. Yes i am commenting out sections of existing code, i didn't comment the code out at the start but

Re: relayd patch for websocket upgrade

On Sun, Mar 07, 2021 at 06:22:04PM -0800, Jonathon Fletcher wrote: > On Sun, Mar 07, 2021 at 06:46:33PM +0100, Marcus MERIGHI wrote: > > Hello Jonathon! > > > > welcome to the party: > > > > https://marc.info/?t=15833439123 > > > > especially the two comments by sthen@: > > > >

Re: sdhc(4) attachment for Zynq-7000

> Date: Sun, 2 May 2021 15:46:30 + > From: Visa Hankala > > On Sun, May 02, 2021 at 05:28:24PM +0200, Mark Kettenis wrote: > > > Date: Sun, 2 May 2021 14:21:29 + > > > From: Visa Hankala > > > > > > Zynq-7000 has a variant of Arasan SD controller that is not recognized > > > by the fdt

Re: diff for wireguard examples on faq17.html

If the manual page is weak, it should be improved. The FAQ cannot make up for it. The FAQ requires online interaction and far fewer people read it. > Sorry accidently replied directly to Theo instead of the list. > > Yes to both of your questions. Sorry if this is noise or spam. > > Section

Re: sdhc(4) attachment for Zynq-7000

On Sun, May 02, 2021 at 05:28:24PM +0200, Mark Kettenis wrote: > > Date: Sun, 2 May 2021 14:21:29 + > > From: Visa Hankala > > > > Zynq-7000 has a variant of Arasan SD controller that is not recognized > > by the fdt glue. The diff below fixes this. > > > > The controller's capabilities regi

Re: sdhc(4) attachment for Zynq-7000

> Date: Sun, 2 May 2021 14:21:29 + > From: Visa Hankala > > Zynq-7000 has a variant of Arasan SD controller that is not recognized > by the fdt glue. The diff below fixes this. > > The controller's capabilities register lacks the base clock frequency. > The attachment glue has to provide thi

Re: Diff for www:FAQ ports/ports

thanks, committed. On 2021/05/02 15:46, b...@stephane-huc.net wrote: > Hi, > > Here a diff for www page: FAQ ports/ports > > Hi, see this typo error on the page. > > Right? > > > Index: faq/ports/ports.html > === > RCS file:

Re: diff for wireguard examples on faq17.html

Isn't a majority of this already in the manual page? Or alternatively, does your attempt to create a FAQ entry indicate that the manual page is weak or unsuitable? > There has been a lot of interest in WireGuard on the OpenBSD subreddit. So > here > is a patch that provides a few basic example

sdhc(4) attachment for Zynq-7000

Zynq-7000 has a variant of Arasan SD controller that is not recognized by the fdt glue. The diff below fixes this. The controller's capabilities register lacks the base clock frequency. The attachment glue has to provide this parameter. OK? Index: dev/fdt/sdhc_fdt.c =

Re: pthread_once fix memory leak

On Sun, May 02, 2021 at 02:07:21PM +0200, Mark Kettenis wrote: > > From: Martijn van Duren > > Date: Sun, 02 May 2021 13:28:10 +0200 > > > > Found this while tracing a memory leak in filter-dkimsign, thanks to > > libcrypto. The mutex in pthread_once_t is never destroyed, so the > > memory alloc

Re: pthread_once fix memory leak

> From: Martijn van Duren > Date: Sun, 02 May 2021 13:28:10 +0200 > > Found this while tracing a memory leak in filter-dkimsign, thanks to > libcrypto. The mutex in pthread_once_t is never destroyed, so the > memory allocated inside the mutex is never released. > > The diff below was inspired by

pthread_once fix memory leak

Found this while tracing a memory leak in filter-dkimsign, thanks to libcrypto. The mutex in pthread_once_t is never destroyed, so the memory allocated inside the mutex is never released. The diff below was inspired by Ed Schouten and switches form mutex to futex to prevent any memory allocation.