On Mon, Jan 24, 2022 at 12:15:58PM -0800, Philip Guenther wrote:
> On Mon, Jan 24, 2022 at 11:41 AM Mark Kettenis
> wrote:
>
> > > Date: Mon, 24 Jan 2022 20:19:46 +0100
> > > From: Anton Lindqvist
> > >
> > > On Mon, Jan 24, 2022 at 05:31:49PM +0100, Mark Kettenis wrote:
> > > > Currently we atta
On Thu, Jan 27, 2022 at 4:03 PM Scott Cheloha
wrote:
> If futimens(2) fails here then close(2) is not called and we leak the
> descriptor.
>
Good catch.
I think futimens(2) and close(2) failures are exotic enough to warrant
> printing the system call name.
>
I don't understand this. Can you
If futimens(2) fails here then close(2) is not called and we leak the
descriptor.
I think futimens(2) and close(2) failures are exotic enough to warrant
printing the system call name.
ok?
Index: touch.c
===
RCS file: /cvs/src/usr.bi
Hi,
I think rpki-client is now an important piece of the DFZ, so it makes
sense to mention it.
Comments? OK?
BTW there's no mention of eigrpd, should we add it? Or there's no need
to list them all?
Cheers,
Daniel
Index: index.html
===
Hi,
kubsan: netinet6/nd6.c:948:42: type mismatch: member access within null pointer
of type 'struct in6_ifaddr'
kubsan: netinet6/nd6_nbr.c:640:43: type mismatch: member access within null
pointer of type 'struct in6_ifaddr'
This codes works as ifaddr ia_ifa is the first field of in6_ifaddr.
So
Hi,
sthen@ complained recently about a multisocket system not being able
to use the TSC in userspace because the sync test measured too much
skew and disabled it.
I don't think there is any real skew on that system. I think the sync
test is confusing NUMA overhead for skew and issuing a false po
On Thu, 27 Jan 2022 15:17:01 +
Miod Vallat wrote:
> > Hi,
> >
> > linking with librpcsvc should be superfluous now.
>
> Then you should also update DPADD to remove $(LIBRPCSVC}...
>
Patch V2
Index: Makefile
===
RCS file: /var
From:
https://en.cppreference.com/w/c/language/main_function
argv- Pointer to the first element of an array of argc + 1 pointers,
of which the last one is null and the previous ones, if any, point to strings
that represent the arguments passed to the program from the host environment.
+ for (; *argv != NULL; argv++)
is argv[1] guaranteed? I have never seen this before.
On Wed, Jan 26, 2022 at 9:52 PM Scott Cheloha
wrote:
> The main loop in head(1) is obfuscated. In particular, the path
> through the loop to exit(3) is extremely clever. Clever in a bad way.
>
On Thu, 27 Jan 2022 08:52:52 -0600, Scott Cheloha wrote:
> Just like with head(1), rev(1)'s main loop is obfuscated.
>
> This patch moves the open/read/write/close portion of the main loop
> out of main() into a separate function, rev_file(). "multibyte"
> becomes a global.
OK millert@
- todd
On Wed, 26 Jan 2022 22:50:27 -0600, Scott Cheloha wrote:
> The main loop in head(1) is obfuscated. In particular, the path
> through the loop to exit(3) is extremely clever. Clever in a bad way.
>
> This patch moves the open/read/write/close portions of the loop out
> into a separate function, h
> Hi,
>
> linking with librpcsvc should be superfluous now.
Then you should also update DPADD to remove $(LIBRPCSVC}...
> Index: Makefile
> ===
> RCS file: /var/cvs/src/usr.bin/passwd/Makefile,v
> retrieving revision 1.41
> diff -u
Hi,
linking with librpcsvc should be superfluous now.
Index: Makefile
===
RCS file: /var/cvs/src/usr.bin/passwd/Makefile,v
retrieving revision 1.41
diff -u -p -r1.41 Makefile
--- Makefile26 Nov 2015 19:01:47 - 1.41
+++ M
Just like with head(1), rev(1)'s main loop is obfuscated.
This patch moves the open/read/write/close portion of the main loop
out of main() into a separate function, rev_file(). "multibyte"
becomes a global.
I think the result is easier to understand at a glance.
In a subsequent patch I want to
On Tue, Jan 25, 2022 at 07:54:52AM +, Klemens Nanni wrote:
> > Could we use a vm_map_assert_locked() or something similar that reflect
> > the exclusive or shared (read) lock comments? I don't trust comments.
> > It's too easy to miss a lock in a code path.
>
> This survives desktop usage, ru
On Thu, Jan 27, 2022 at 07:46:32AM +0100, Theo Buehler wrote:
> On Wed, Jan 26, 2022 at 04:42:04PM +0100, Claudio Jeker wrote:
> > So the RFC is not very clear but in general the idea is that if multiple
> > MFTs are available the newest one (highest manifest number) should be
> > used.
> >
> > In
16 matches
Mail list logo