On Wed, Dec 21, 2022 at 05:15:35PM -0500, Paul Tagliamonte wrote:
> Good news, I've got my MUA sorted. Hopefully this fixes the issues with
> the CVS diffs in my reply body.
>
> On Wed, Dec 21, 2022 at 10:09:24PM +, Jason McIntyre wrote:
> > i like the choice of "display" over "print out".
> >
On Sun, Dec 18, 2022 at 08:10:48PM +0100, Otto Moerbeek wrote:
> Hi,
>
> This is the latest verion of a diff I sent around previously, but now
> it's time this gets wider testing for real.
>
> The main purpose is to rearrange malloc init in such a way that a few
> pages containing mallic interna
Jeremie Courreges-Anglas wrote:
> On Wed, Dec 21 2022, "Theo de Raadt" wrote:
> >> But yeah, maybe we'll just flip the default option in LLVM and then
> >> we'll just not use that warning... at all?
> >
> > is this specific warning finding dangerous bugs? is it finding a
> > substantial
> > nu
On Wed, Dec 21 2022, "Theo de Raadt" wrote:
>> But yeah, maybe we'll just flip the default option in LLVM and then
>> we'll just not use that warning... at all?
>
> is this specific warning finding dangerous bugs? is it finding a substantial
> number of dangerous bugs?
No, but if we remove -Wdep
> So for base we don't really need to tweak the defaults, I'd
> rather see what happens in ports wrt -Wdeprecated-non-prototype, and
> I don't think it's the biggest offender.
If libz is hitting this, then I think the situation will be dire in
ports.
I think the clang developers are so busy chasi
On Thu, Dec 22 2022, Patrick Wildt wrote:
> Am Thu, Dec 22, 2022 at 01:57:37AM +0100 schrieb Jeremie Courreges-Anglas:
>> On Thu, Dec 22 2022, Theo Buehler wrote:
>> > On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
>> >> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote
> But yeah, maybe we'll just flip the default option in LLVM and then
> we'll just not use that warning... at all?
is this specific warning finding dangerous bugs? is it finding a substantial
number of dangerous bugs?
On Tue, Dec 20 2022, Todd C. Miller wrote:
> On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote:
>
>> clang complains when the function is declared with a fixed array size in
>> a parameter while the prototype is unbounded, like this:
>>
>> /usr/src/sys/net/pf.c:4353:54: error: argument 'sns'
Am Thu, Dec 22, 2022 at 01:57:37AM +0100 schrieb Jeremie Courreges-Anglas:
> On Thu, Dec 22 2022, Theo Buehler wrote:
> > On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
> >> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
> >> > > Any concerns regarding the changes in
On Thu, Dec 22 2022, Theo Buehler wrote:
> On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
>> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
>> > > Any concerns regarding the changes in libz? It introduces diff to
>> > > upstream, but the recent commits seemed to ind
Theo Buehler wrote:
> On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
> > On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
> > > > Any concerns regarding the changes in libz? It introduces diff to
> > > > upstream, but the recent commits seemed to indicate we have for
On Thu, Dec 22, 2022 at 11:39:41AM +1100, Jonathan Gray wrote:
> On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
> > > Any concerns regarding the changes in libz? It introduces diff to
> > > upstream, but the recent commits seemed to indicate we have forked
> > > anyway?
> >
> > I'v
On Thu, Dec 22, 2022 at 01:20:32AM +0100, Theo Buehler wrote:
> > Any concerns regarding the changes in libz? It introduces diff to
> > upstream, but the recent commits seemed to indicate we have forked
> > anyway?
>
> I've worked hard to keep the diff to upstream minimal. Why are these
> changes
Theo Buehler wrote:
> > Any concerns regarding the changes in libz? It introduces diff to
> > upstream, but the recent commits seemed to indicate we have forked
> > anyway?
>
> I've worked hard to keep the diff to upstream minimal. Why are these
> changes needed?
becauase clang believes they a
> Any concerns regarding the changes in libz? It introduces diff to
> upstream, but the recent commits seemed to indicate we have forked
> anyway?
I've worked hard to keep the diff to upstream minimal. Why are these
changes needed?
On Tue, Dec 20, 2022 at 05:48:41PM -0700, Todd C. Miller wrote:
> On Tue, 20 Dec 2022 23:44:08 +0100, Patrick Wildt wrote:
>
> > clang complains when the function is declared with a fixed array size in
> > a parameter while the prototype is unbounded, like this:
> >
> > /usr/src/sys/net/pf.c:4353:
The first one replaces malloc(9) related M_NOWAIT and M_WAITOK flags we
use with sblock() to wait for lock if not immediately available.
The second one proposed to use if the lock awaiting should be
uninterruptible. It affects on sblock() behaviour for this call, instead
of SB_NOINTR flag which gl
Jason McIntyre wrote:
> i would not remove the Xr. i think if we go ahead with this, we can make
> a separate commit where we point people to route(8) rather than
> netstart(8), but i suspect many pages will both want references to both.
netstat, not netstart, heh
But yes it is true that some l
Good news, I've got my MUA sorted. Hopefully this fixes the issues with
the CVS diffs in my reply body.
On Wed, Dec 21, 2022 at 10:09:24PM +, Jason McIntyre wrote:
> i like the choice of "display" over "print out".
> i don;t like the "related metadata" bit though.
>
> what about just
>
>
On Wed, Dec 21, 2022 at 12:41:42PM -0500, Paul R. Tagliamonte wrote:
> > So I think route.8 is where we should try to have complete documentation,
> > and once that is done we should change Xr's and other documentation to
> > point at route.8 instead of netstat.8
>
> In an effort to have my intera
On Wed, Dec 21, 2022 at 01:08:14PM +0100, Claudio Jeker wrote:
> In general I think finding such errors quickly would be nice.
> Is there a way to make this a compile time error? I guess that requires
> some ugly macro magic.
I agree a compile time check would be better but I don't have
a good ide
> So I think route.8 is where we should try to have complete documentation,
> and once that is done we should change Xr's and other documentation to
> point at route.8 instead of netstat.8
In an effort to have my interactions on this list wind up being helpful
rather than more work for overworked
Claudio Jeker wrote:
> In the old world only netstat could show the routing table. I think this
> is still the case in FreeBSD for example. We added route show at some
> point but the documentation was not shared between the manpages.
> I agree that it is annoying to open up the netstat man page
On Wed, Dec 21, 2022 at 04:48:38PM +, Jason McIntyre wrote:
> On Wed, Dec 21, 2022 at 10:43:18AM -0500, Paul R. Tagliamonte wrote:
> > On Tue, Dec 20, 2022 at 8:27 PM Paul R. Tagliamonte
> > wrote:
> > >
> > > Heyya tech@,
> > >
> > > Please keep me on cc, I'm not subscribed
> >
> > Please k
On Wed, Dec 21, 2022 at 10:43:18AM -0500, Paul R. Tagliamonte wrote:
> On Tue, Dec 20, 2022 at 8:27 PM Paul R. Tagliamonte wrote:
> >
> > Heyya tech@,
> >
> > Please keep me on cc, I'm not subscribed
>
> Please keep me on cc. The last message wasn't sent to me, so my In-Reply-To
> is going to be
Theo de Raadt wrote:
> A few weeks ago a conversation about retguard (a diff is probably
> coming) caused me re-consider & re-read the BROP paper
>
> https://www.scs.stanford.edu/brop/bittau-brop.pdf
new version of the diff. The small piece of locking has been improved
by using a private
On Tue, Dec 20, 2022 at 8:27 PM Paul R. Tagliamonte wrote:
>
> Heyya tech@,
>
> Please keep me on cc, I'm not subscribed
Please keep me on cc. The last message wasn't sent to me, so my In-Reply-To
is going to be wrong. I'm not subscribed to tech@.
>From the web:
> some of the relevant flags are
On Tue, Dec 13, 2022 at 12:33:03AM +0100, Michael Knudsen wrote:
> We can detect this class of error by redefining the flags to
> use the high bits instead of the low ones. This way the malloc()
> KMEMSTAT value check triggers because 0x1000 is greater than
> the maximum type value.
>
> I tes
28 matches
Mail list logo
