> On Mar 29, 2025, at 9:38 PM, Taylor R Campbell wrote:
>
> This is still broken: now it doesn't read past the end the input
> buffer, but it leaves the bytes bi->bi_msg[rem], bi->bi_msg[rem + 1],
> bi->bi_msg[rem + 2] ..., bi->bi_msg[sizeof(bi->bi_msg) - 2]
> uninitialized, and will later dump
Date:Sun, 30 Mar 2025 01:38:51 +
From:Taylor R Campbell
Message-ID: <20250330013852.a346284...@mail.netbsd.org>
| but it leaves the bytes bi->bi_msg[rem], bi->bi_msg[rem + 1],
| bi->bi_msg[rem + 2] ..., bi->bi_msg[sizeof(bi->bi_msg) - 2]
| uninitialized,
I
> Module Name:src
> Committed By: christos
> Date: Sat Mar 29 23:25:57 UTC 2025
>
> Modified Files:
> src/external/bsd/blocklist/lib: bl.c
>
> Log Message:
> Don't use strlcpy() because it will keep going trying to find the end of the
> input string (thanks riastradh)
>
>
> Module Name:src
> Committed By: christos
> Date: Wed Mar 26 13:52:47 UTC 2025
>
> Modified Files:
> src/external/bsd/blocklist/lib: bl.c
>
> Log Message:
> NUL-terminate the message string (thanks riastradh)
>
>
> To generate a diff of this commit:
> cvs rdiff -u -r1.5
On Fri, Apr 19, 2024 at 10:48:10PM +0700, Robert Elz wrote:
> Date:Fri, 19 Apr 2024 14:58:18 +
> From:"Jonathan A. Kollasch"
> Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
>
> | - bail out if resulting __DATE__/__TIME__ replacement strings are empty
>
Date:Fri, 19 Apr 2024 14:58:18 +
From:"Jonathan A. Kollasch"
Message-ID: <20240419145818.351d2f...@cvs.netbsd.org>
| - bail out if resulting __DATE__/__TIME__ replacement strings are empty
If you want to do that (not that it would be useful, even if the %b
(et
On Fri 19 Apr 2024 at 14:47:23 +0200, Martin Husemann wrote:
> The problem (IIUC) is that the ntp code parses this value internally, so
> it won't talk to anyone claiming a time before the time ntpd was compiled
> (or something along that line).
Would it make sense to just supply a fixed string to
Date:Fri, 19 Apr 2024 14:57:46 +0200
From:Martin Husemann
Message-ID: <20240419125746.gb26...@mail.duskware.de>
| On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
| > The commit message could have explained that a bit.
|
| And it actually shoul
On Fri, Apr 19, 2024 at 02:47:23PM +0200, Martin Husemann wrote:
> The commit message could have explained that a bit.
And it actually should have been "+%b %e %Y" - from the C18 standard draft:
6.10.8.1 Mandatory macros
__DATE__
The date of translation of the preprocessing translation unit: a
On Fri, Apr 19, 2024 at 04:36:46PM +0700, Robert Elz wrote:
> I don't understand that change, it altered from
>
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%F"
> to
> MKREPRO_DATE != ${TOOL_DATE} -u -r "${MKREPRO_TIMESTAMP}" "+%b %d %Y"
>
> %F is simply a shorthand f
Date:Thu, 18 Apr 2024 19:23:54 +
From:"Jonathan A. Kollasch"
Message-ID: <20240418192354.1bcc1f...@cvs.netbsd.org>
| Module Name:src
| Committed By: jakllsch
| Date: Thu Apr 18 19:23:54 UTC 2024
|
| Modified Files:
| src
> Date: Thu, 29 Jun 2023 16:51:05 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article <20230628222148.710dbf...@cvs.netbsd.org>,
> Thomas Klausner wrote:
> >-=-=-=-=-=-
> >
> [...]
> >+-DTMUX_CONF='"/etc/tmux.conf:~/.tmux.conf:$XDG_CONFIG_HOME/tmux/tmux.conf:~/.config/tmux/tm
In article <20230628222148.710dbf...@cvs.netbsd.org>,
Thomas Klausner wrote:
>-=-=-=-=-=-
>
[...]
>+-DTMUX_CONF='"/etc/tmux.conf:~/.tmux.conf:$XDG_CONFIG_HOME/tmux/tmux.conf:~/.config/tmux/tmux.conf"'
> \
What is XDG_CONFIG_HOME?
christos
On 30.04.2021 15:42, Tobias Nygren wrote:
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
Module Name:src
Committed By: rillig
Date: Tue Apr 20 23:19:53 UTC 2021
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
Log Message:
clang: fix
On Tue, 20 Apr 2021 23:19:53 +
Roland Illig wrote:
> Module Name: src
> Committed By: rillig
> Date: Tue Apr 20 23:19:53 UTC 2021
>
> Modified Files:
> src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
>
> Log Message:
> clang: fix build for installing libclang_rt.ub
"Andreas Gustafsson" wrote:
> Module Name: src
> Committed By: gson
> Date: Sat Apr 10 10:32:57 UTC 2021
>
> Modified Files:
>
> src/external/bsd/atf/dist/tools: atf-run.1 atf-run.cpp
>
> Log Message:
>
> Add support for running individual test cases under isolation.
Thank you! Th
Too bad, looks like they just made a copy of the FreeBSD changes. I will revert.
christos
> On Feb 25, 2021, at 6:47 PM, Rin Okuyama wrote:
>
> Hi,
>
> This does not work since nvi requires non-standard wregex API, whose
> ``char *'' arguments are replaced by ``wchar_t *'' ones:
>
> https://m
Hi,
This does not work since nvi requires non-standard wregex API, whose
``char *'' arguments are replaced by ``wchar_t *'' ones:
https://mail-index.netbsd.org/tech-userlevel/2008/08/06/msg000960.html
https://mail-index.netbsd.org/tech-userlevel/2008/08/06/msg000967.html
In principle, we can re
Hi Roy !
That looks more semantics (the ones I know of - dynamic interface
scanning is one of my NTPd parts)
preserving now.
So far I see no other issues from the pitfalls I know of.
Lets hope our kernel and other SO_RERRORS systems miss any
interface scan worthy events.
Frank
On 01/03/2
On 02/01/2021 23:33, Frank Kardel wrote:
Also the behavior now fully relies in the routing message functionality which
can be disabled
on serious procession errors - at that point the code robustness relies on the
periodic
re-scanning - so I am not sure whether the periodic re-scanning shoul
On 02/01/2021 23:33, Frank Kardel wrote:
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
...
This patch seems (by visual inspection) to brea
Hi Roy !
This may look like a better solution from the interface tracking side.
People have requested being able to disable dynamic interface updates
completely.
This was implemented via the -U 0.
See man ntpd:
...
−U number, −−updateinterval=number
interval in seconds
On 02/01/2021 17:23, Roy Marples wrote:
That's a good point, with this we can now remove that forced sync on a timer
approach.
Does this look ok?
Better patch:
diff -r 9e64cf4881a1 external/bsd/ntp/dist/ntpd/ntp_io.c
--- a/external/bsd/ntp/dist/ntpd/ntp_io.c Sat Jan 02 12:39:33 2021 +0
Hi Frank
On 02/01/2021 09:55, Frank Kardel wrote:
I doubt that the explicit draining is helpful here as it already happens
I was aware of that.
I was just trying to avoid excess timer interface timeouts if we don't get
around to reading the next message in UPDATE_GRACE time.
Let's see what u
Hi Roy !
I doubt that the explicit draining is helpful here as it already happens
in the outer loop processing any routing socket input. All that is happening
in the routing messages processing path is to call
timer_interfacetimeout(current_time + UPDATE_GRACE) and
this is robust for multipl
Date:Fri, 1 Jan 2021 20:38:36 +
From:"Roy Marples"
Message-ID: <20210101203836.2cadcf...@cvs.netbsd.org>
| Modified Files:
| src/external/bsd/unbound/lib/libunbound: Makefile
|
| Log Message:
| libunbound: Now we use libevent, don't build mini_event
I've asked.
Best,
christos
> On Nov 1, 2020, at 11:19 AM, Kimmo Suominen wrote:
>
>> Log Message:
>> CHANGED FROM 3.1b TO 3.1c
>>
>> * Do not write after the end of the array and overwrite the stack when
>> colon-separated SGR sequences contain empty arguments.
>
> Pullup to -9 and -8 for s
> Log Message:
> CHANGED FROM 3.1b TO 3.1c
>
> * Do not write after the end of the array and overwrite the stack when
> colon-separated SGR sequences contain empty arguments.
Pullup to -9 and -8 for security fix?
https://mail-index.netbsd.org/source-changes/2020/11/01/msg123671.html
In article <20200702140653.gf12...@mewburn.net>,
Luke Mewburn wrote:
>On 20-06-21 18:23, Christos Zoulas wrote:
> | In article <20200621142616.60471f...@cvs.netbsd.org>,
> | Luke Mewburn wrote:
> | >-=-=-=-=-=-
> | >
> | >Module Name: src
> | >Committed By: lukem
> | >Date:
On 20-06-21 18:23, Christos Zoulas wrote:
| In article <20200621142616.60471f...@cvs.netbsd.org>,
| Luke Mewburn wrote:
| >-=-=-=-=-=-
| >
| >Module Name: src
| >Committed By: lukem
| >Date: Sun Jun 21 14:26:16 UTC 2020
| >
| >Modified Files:
| > src/e
In article <20200621142616.60471f...@cvs.netbsd.org>,
Luke Mewburn wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: lukem
>Date: Sun Jun 21 14:26:16 UTC 2020
>
>Modified Files:
> src/external/bsd/kyua-cli: Makefile.inc
>
>Log Message:
>kyua-cli: avoid warning about deprecat
On 29.05.2020 16:15, Tobias Nygren wrote:
> On Fri, 29 May 2020 16:08:30 +0200
> Joerg Sonnenberger wrote:
>
>> On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Fri May 29 10:53:02 UTC 2020
>>>
>>>
On Fri, 29 May 2020 16:08:30 +0200
Joerg Sonnenberger wrote:
> On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
> > Module Name:src
> > Committed By: kamil
> > Date: Fri May 29 10:53:02 UTC 2020
> >
> > Modified Files:
> > src/external/bsd/ntp/bin
On Fri, May 29, 2020 at 10:53:02AM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Fri May 29 10:53:02 UTC 2020
>
> Modified Files:
> src/external/bsd/ntp/bin/ntpd: Makefile
>
> Log Message:
> Fix the ntpd build with Clang/LLVM
>
> Set -Wno-format-n
In article <95034282-ebf6-c1d5-8bb1-9258ee825...@marples.name>,
Roy Marples wrote:
>On 10/05/2020 18:58, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sun May 10 17:58:16 UTC 2020
>>
>> Modified Files:
>> src/external/bsd/dhcpcd/dist/src
On 10/05/2020 18:58, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun May 10 17:58:16 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcpcd.c
Log Message:
Add SIGPIPE to the list of dhcpcd affected signals since we sigignore it.
Why?
>
> I'll revert this for the time being.
Thanks, I am working on fixing the routing socket to have a perms check.
christos
signature.asc
Description: Message signed with OpenPGP
> If we just re-add the rule, we should either get an error that it already
> exists which we should gracefully handle or it just overwrites the existing
> rule.
> I don't see the point in deleting something which by your logic is already
> deleted.
Yes, we could re-add unconditionally. Is tha
On 11/03/2020 15:02, Christos Zoulas wrote:
In article <20200311021208.bfb5cf...@cvs.netbsd.org>,
Roy Marples wrote:
-=-=-=-=-=-
Module Name:src
Committed By: roy
Date: Wed Mar 11 02:12:08 UTC 2020
Modified Files:
src/external/bsd/blacklist/bin: blacklistd.c conf.c
On 11/03/2020 15:12, Christos Zoulas wrote:
In article <20200311023318.c6a7ff...@cvs.netbsd.org>,
Roy Marples wrote:
-=-=-=-=-=-
Module Name:src
Committed By: roy
Date: Wed Mar 11 02:33:18 UTC 2020
Modified Files:
src/external/bsd/blacklist/bin: blacklistd.c
Log Messa
In article <20200311023318.c6a7ff...@cvs.netbsd.org>,
Roy Marples wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: roy
>Date: Wed Mar 11 02:33:18 UTC 2020
>
>Modified Files:
> src/external/bsd/blacklist/bin: blacklistd.c
>
>Log Message:
>blacklist: Don't remove a ruleset if
In article <20200311021208.bfb5cf...@cvs.netbsd.org>,
Roy Marples wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: roy
>Date: Wed Mar 11 02:12:08 UTC 2020
>
>Modified Files:
> src/external/bsd/blacklist/bin: blacklistd.c conf.c
> src/external/bsd/blacklist/lib: bl.c
>
Earlier, I wrote:
> > cvs rdiff -u -r1.1.1.4 -r1.2 \
> > src/external/bsd/libarchive/dist/libarchive/archive_read.c
>
> What kind of sorcery is this? Why is the diff not relative to 1.1?
To answer my own question, "vendor branch sorcery". What confused me
about this in the first place was t
I repled to you and gson off-list.
> On Feb 25, 2020, at 8:24 AM, Kamil Rytarowski wrote:
>
> On 25.02.2020 16:24, Andreas Gustafsson wrote:
>> Kamil Rytarowski wrote:
>>> To generate a diff of this commit:
>>> cvs rdiff -u -r1.1.1.4 -r1.2 \
>>>src/external/bsd/libarchive/dist/libarchive/arc
On 25.02.2020 16:24, Andreas Gustafsson wrote:
> Kamil Rytarowski wrote:
>> To generate a diff of this commit:
>> cvs rdiff -u -r1.1.1.4 -r1.2 \
>> src/external/bsd/libarchive/dist/libarchive/archive_read.c
>
> What kind of sorcery is this? Why is the diff not relative to 1.1?
>
I don't kno
Kamil Rytarowski wrote:
> To generate a diff of this commit:
> cvs rdiff -u -r1.1.1.4 -r1.2 \
> src/external/bsd/libarchive/dist/libarchive/archive_read.c
What kind of sorcery is this? Why is the diff not relative to 1.1?
--
Andreas Gustafsson, g...@gson.org
On 24.02.2020 17:44, Valery Ushakov wrote:
> On Mon, Feb 24, 2020 at 16:19:35 +, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Mon Feb 24 16:19:35 UTC 2020
>>
>> Modified Files:
>> src/external/bsd/tcpdump/dist: extract.h
>>
>> Log Mes
On Mon, Feb 24, 2020 at 16:19:35 +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Mon Feb 24 16:19:35 UTC 2020
>
> Modified Files:
> src/external/bsd/tcpdump/dist: extract.h
>
> Log Message:
> Rearrange the code to make UNALIGNED_OK available for __N
On 14/02/2020 20:36, Santhosh Raju wrote:
On Thu, Feb 13, 2020 at 4:44 PM Santhosh Raju wrote:
On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
On 13.02.2020 22:20, Valery Ushakov wrote:
I did not propose to disable the warning. I proposed to downgrade
-Werror to -Wno-error (i.e. a
On Thu, Feb 13, 2020 at 4:44 PM Santhosh Raju wrote:
>
> On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
> >
> > On 13.02.2020 22:20, Valery Ushakov wrote:
> > > I did not propose to disable the warning. I proposed to downgrade
> > > -Werror to -Wno-error (i.e. a warning) and only for th
On Thu, Feb 13, 2020 at 4:32 PM Kamil Rytarowski wrote:
>
> On 13.02.2020 22:20, Valery Ushakov wrote:
> > I did not propose to disable the warning. I proposed to downgrade
> > -Werror to -Wno-error (i.e. a warning) and only for the buggy
> > sanitizer build. That file will still be compiled in
On 13.02.2020 22:20, Valery Ushakov wrote:
> I did not propose to disable the warning. I proposed to downgrade
> -Werror to -Wno-error (i.e. a warning) and only for the buggy
> sanitizer build. That file will still be compiled in normal builds
> with all the warnings=errors enabled, so real probl
On Thu, Feb 13, 2020 at 18:25:41 +0100, Kamil Rytarowski wrote:
> On 13.02.2020 18:00, Valery Ushakov wrote:
> > Arguably, if the tool you use is broken, you shouln't be mutilating
> > the source code just to shut that tool up.
>
> The introduced changes were good, even if GCC would be silent.
On 13.02.2020 18:00, Valery Ushakov wrote:
> Arguably, if the tool you use is broken, you shouln't be mutilating
> the source code just to shut that tool up.
The introduced changes were good, even if GCC would be silent. It is far
from mutilating. As an alternative option we can disable warnings
On Thu, Feb 13, 2020 at 15:03:35 +0100, Kamil Rytarowski wrote:
> On 13.02.2020 14:50, Valery Ushakov wrote:
> > On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
> >
> > Can you show the original problem that you are trying to fix here?
> > When and how did you get warning?
>
> GC
On 13.02.2020 14:50, Valery Ushakov wrote:
> On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
>
>>
> Can you show the original problem that you are trying to fix here?
> When and how did you get warning?
>
GCC has a property (as called by Joerg bug) that different backend,
differ
On Thu, Feb 13, 2020 at 14:18:43 +0100, Kamil Rytarowski wrote:
> Feel free to fix GCC.
That's sounds rather dismissive to me.
Can you show the original problem that you are trying to fix here?
When and how did you get warning?
I do NOT see the warning for this kind of conversion with either
cu
On 13.02.2020 14:13, Joerg Sonnenberger wrote:
> On Thu, Feb 13, 2020 at 02:05:12PM +0100, Kamil Rytarowski wrote:
>> On 13.02.2020 00:58, Joerg Sonnenberger wrote:
>>> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> On Sat, Feb
On Thu, Feb 13, 2020 at 02:05:12PM +0100, Kamil Rytarowski wrote:
> On 13.02.2020 00:58, Joerg Sonnenberger wrote:
> > On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> >> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> >>> On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote
On 13.02.2020 00:58, Joerg Sonnenberger wrote:
> On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
>> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
>>> On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name: src
Committed By: fox
Date:
Date:Thu, 13 Feb 2020 02:45:44 +
From:Roy Marples
Message-ID:
| My understanding was if it could be promoted to an int it would be.
| So it size_t is bigger in bits than uint16_t and int is also bigger then
| promotion occurs and we then have signed vs uns
On 13/02/2020 02:17, Joerg Sonnenberger wrote:
I thought this fell under int promotion and thus became signed vs unsigned?
size_t is guaranteed to be at least 16bit. If INT_MAX == 32767, an
implicit cast of uint16_t would go to unsigned anyway and in all other
cases, any implicit cast must be v
On Thu, Feb 13, 2020 at 02:07:23AM +, Roy Marples wrote:
> On 12/02/2020 23:58, Joerg Sonnenberger wrote:
> > On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> > > On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> > > > On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
On 12/02/2020 23:58, Joerg Sonnenberger wrote:
On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name:src
Committed By: fox
Date: Sat Feb 8 12:17:16
On Mon, Feb 10, 2020 at 04:45:35PM +, Roy Marples wrote:
> On 09/02/2020 19:21, Joerg Sonnenberger wrote:
> > On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
> > > Module Name: src
> > > Committed By: fox
> > > Date: Sat Feb 8 12:17:16 UTC 2020
> > >
> > >
On 09/02/2020 19:21, Joerg Sonnenberger wrote:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
Module Name:src
Committed By: fox
Date: Sat Feb 8 12:17:16 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: dhcp.c
Log Message:
external/bsd/dhcpcd:
On Sat, Feb 08, 2020 at 12:17:16PM +, Santhosh Raju wrote:
> Module Name: src
> Committed By: fox
> Date: Sat Feb 8 12:17:16 UTC 2020
>
> Modified Files:
> src/external/bsd/dhcpcd/dist/src: dhcp.c
>
> Log Message:
> external/bsd/dhcpcd: Fix a -Wconversion warning.
>
> Type ca
On 29/01/2020 23:42, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Wed Jan 29 23:42:58 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/sbin/dhcpcd: Makefile
Log Message:
Hack for clang/powerpc
What error does this solve?
Thanks. Yes, I have the core-dump, no we should not remove the line...
Best,
christos
> On Jan 27, 2020, at 8:03 AM, Roy Marples wrote:
>
> On 27/01/2020 09:03, Roy Marples wrote:
>> On 26/01/2020 22:57, Christos Zoulas wrote:
>>> Module Name:src
>>> Committed By:christos
>>> Date:
On 27/01/2020 09:03, Roy Marples wrote:
On 26/01/2020 22:57, Christos Zoulas wrote:
Module Name: src
Committed By: christos
Date: Sun Jan 26 22:57:52 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: script.c
Log Message:
prevent coredump when state == NULL
To gener
On 26/01/2020 22:57, Christos Zoulas wrote:
Module Name:src
Committed By: christos
Date: Sun Jan 26 22:57:52 UTC 2020
Modified Files:
src/external/bsd/dhcpcd/dist/src: script.c
Log Message:
prevent coredump when state == NULL
To generate a diff of this commit:
cvs rdif
"Christos Zoulas" writes:
> Module Name: src
> Committed By: christos
> Date: Fri Aug 9 08:10:39 UTC 2019
>
> Modified Files:
> src/external/bsd/jemalloc/include/jemalloc/internal:
> jemalloc_internal_defs.h
>
> Log Message:
> PR/54307: Rin Okuyama: Lots of jemalloc asse
Date:Sat, 6 Apr 2019 08:29:02 +
From:"Robert Elz"
Message-ID: <20190406082902.1da38f...@cvs.netbsd.org>
| Module Name:src
| Committed By: kre
| Date: Sat Apr 6 08:29:02 UTC 2019
|
| Modified Files:
| src/external/bsd/pk
In article <20190403062742.ga5...@homeworld.netbsd.org>,
wrote:
>Email as a reminder that sun2 also relies on emutls and probably needs
>the same
I am testing it now...
christos
Email as a reminder that sun2 also relies on emutls and probably needs
the same
On Tue, Apr 02, 2019 at 05:19:21PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Tue Apr 2 21:19:20 UTC 2019
>
> Modified Files:
> src/external/bsd/jemalloc/include/
Kamil Rytarowski writes:
> I've pushed a fix to unbreak the build.
>
> Now we have a mismatch mallctlnametomib vs mallctltomib in malloc.h.
>
> Which one is correct?
Rather obviously mallctlnametomib, I'd say - that's the one that's
described in external/bsd/jemalloc/dist/doc/jemalloc.3.
-tih
-
On 10.03.2019 10:21, Kamil Rytarowski wrote:
> On 10.03.2019 10:00, Tom Ivar Helbekkmo wrote:
>> Christos Zoulas writes:
>>
>>> Module Name:src
>>> Committed By: christos
>>> Date: Sun Mar 10 02:49:52 UTC 2019
>>>
>>> Modified Files:
>>> src/external/bsd/jemalloc/di
On 10.03.2019 10:00, Tom Ivar Helbekkmo wrote:
> Christos Zoulas writes:
>
>> Module Name: src
>> Committed By:christos
>> Date:Sun Mar 10 02:49:52 UTC 2019
>>
>> Modified Files:
>> src/external/bsd/jemalloc/dist/src: jemalloc.c
>> src/external/bsd/jemalloc/inclu
Christos Zoulas writes:
> Module Name: src
> Committed By: christos
> Date: Sun Mar 10 02:49:52 UTC 2019
>
> Modified Files:
> src/external/bsd/jemalloc/dist/src: jemalloc.c
> src/external/bsd/jemalloc/include/jemalloc: jemalloc.h
> src/external/bsd/jemalloc/lib: Makefi
In article <20190109092730.00052f...@cvs.netbsd.org>,
Martin Husemann wrote:
> aslcompilerparse.y: aslparser.y
>- ${TOOL_M4} -P -I${TOPDIR} ${.ALLSRC} > ${.TARGET}
>+ ${TOOL_M4} -P -I${TOPDIR} ${.ALLSRC} > ${.TARGET}.tmp \
>+ && mv ${.TARGET}.tmp ${.TARGET}
Looks to me like one pr
Oops, sorry. Wrong mail address.
On 2018/12/13 20:54, Masanobu SAITOH wrote:
Please pullup the following change to netbsd-8 branch.
On 2018/12/12 15:36, SAITOH Masanobu wrote:
Module Name: src
Committed By: msaitoh
Date: Wed Dec 12 06:36:13 UTC 2018
Modified Files:
src/exte
Please pullup the following change to netbsd-8 branch.
On 2018/12/12 15:36, SAITOH Masanobu wrote:
Module Name:src
Committed By: msaitoh
Date: Wed Dec 12 06:36:13 UTC 2018
Modified Files:
src/external/bsd/file/lib: Makefile
Log Message:
Use DPSRCS for magic.h. OK'd b
On 22/09/2018 14:17, Robert Elz wrote:
Module Name:src
Committed By: kre
Date: Sat Sep 22 13:17:46 UTC 2018
Modified Files:
src/external/bsd/dhcpcd/dist/hooks: 20-resolv.conf 29-lookup-hostname
30-hostname 50-ntp.conf 50-yp.conf 50-ypbind.in dhcpcd-run-hooks.i
On 04.08.2018 05:44, Robert Elz wrote:
> Date:Sat, 4 Aug 2018 04:24:01 +0200
> From:Kamil Rytarowski
> Message-ID: <568544f4-36d5-853e-cdf8-248f84fad...@gmx.com>
>
> | I haven't changed any optimization or similar flags for the builds.
>
> Then why did the ssh exam
Date:Sat, 4 Aug 2018 04:24:01 +0200
From:Kamil Rytarowski
Message-ID: <568544f4-36d5-853e-cdf8-248f84fad...@gmx.com>
| I haven't changed any optimization or similar flags for the builds.
Then why did the ssh example start giving "perhaps used uninit" warnings
when
On 04.08.2018 03:23, Robert Elz wrote:
> Date:Sat, 4 Aug 2018 02:15:15 +0200
> From:Kamil Rytarowski
> Message-ID:
>
>
> | In general there shall not be a relation between -O level and
> | sanitizers. Sanitizers do not need -O0 or -g for operation.
>
> That's
Date:Sat, 4 Aug 2018 02:15:15 +0200
From:Kamil Rytarowski
Message-ID:
| In general there shall not be a relation between -O level and
| sanitizers. Sanitizers do not need -O0 or -g for operation.
That's fine. But are you doing compiles that way? (necessary
On 04.08.2018 01:31, Robert Elz wrote:
> Kamil: assuming you agree that this is a reasonable analysis, I'd suggest
> no more code changes based upon gcc warnings issued this way.
In general there shall not be a relation between -O level and
sanitizers. Sanitizers do not need -O0 or -g for operati
Date:Fri, 3 Aug 2018 23:05:10 +0100
From:Roy Marples
Message-ID: <4c9d72c8-cfd6-64dd-dd67-2406d4edc...@marples.name>
| So casting to (size_t) is the Right Thing To Do and no comment required?
For now it might be the right thing to do. But it should have a comment
On 03/08/2018 23:03, Valery Ushakov wrote:
On Fri, Aug 03, 2018 at 18:08:24 +0300, Valery Ushakov wrote:
On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
Where is the signed arithmetic that was supposedly a probem?
A
On Fri, Aug 03, 2018 at 18:08:24 +0300, Valery Ushakov wrote:
> On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
>
> > On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> > > Where is the signed arithmetic that was supposedly a probem?
> >
> > Ah, stupid C integer promoti
On Fri, Aug 03, 2018 at 07:46:01PM +0100, Roy Marples wrote:
> We could split the term, but merely storing the result of htons in it's own
> variable creates a larger binary for no good reason as i see it.
>
I suspect that the compiler will generate the same code anyway when
using a local variabl
Date:Fri, 3 Aug 2018 19:46:01 +0100
From:Roy Marples
Message-ID:
| Considering both methods work and the result of htons is a uint16_t (but
| is this always guaranteed?)
ntohs() (not that it matters) and "always" is a big word, but that is how
it is defined by
On 03.08.2018 20:49, Roy Marples wrote:
> On 03/08/2018 15:22, Robert Elz wrote:
>> Whether there need to be any attention to the possibility
>> of a malformed packet I will leave for Roy to decide (I am
>> assuming probably not) but that added cast just looks to be
>> a bandaid for a broken compil
On 03/08/2018 15:22, Robert Elz wrote:
Whether there need to be any attention to the possibility
of a malformed packet I will leave for Roy to decide (I am
assuming probably not) but that added cast just looks to be
a bandaid for a broken compiler (sanitiser).
The contents are verified further
On 03/08/2018 14:02, Martin Husemann wrote:
On Fri, Aug 03, 2018 at 02:47:53PM +0200, Kamil Rytarowski wrote:
Further if there ever was a potential problem from this line ...
*len = ntohs(p->ip.ip_len) - sizeof(p->ip) - sizeof(p->udp);
then
*len = (size_t)ntohs(p->ip.ip_len) - s
On Fri, Aug 03, 2018 at 15:54:24 +0200, Martin Husemann wrote:
> On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> > Where is the signed arithmetic that was supposedly a probem?
>
> Ah, stupid C integer promotion rules. uint16_t is promoted to int
> here, not unsigned int or size_t.
Date:Fri, 3 Aug 2018 15:54:24 +0200
From:Martin Husemann
Message-ID: <20180803135424.gc23...@mail.duskware.de>
| Ah, stupid C integer promotion rules. uint16_t is promoted to int
| here, not unsigned int or size_t.
Even with that, there should be no problem, in
On Fri, Aug 03, 2018 at 08:28:55PM +0700, Robert Elz wrote:
> Where is the signed arithmetic that was supposedly a probem?
Ah, stupid C integer promotion rules. uint16_t is promoted to int
here, not unsigned int or size_t. The cast makes all operands the same
type and no promotion happens.
Martin
Date:Fri, 3 Aug 2018 15:02:28 +0200
From:Martin Husemann
Message-ID: <20180803130227.ga23...@mail.duskware.de>
| What exactly makes the code safe now? If ntohs(p->ip.ip_len) <
| (sizeof(p->ip) + sizeof(p->udp)) then we are now in even more serious
| trouble.
Ac
1 - 100 of 334 matches
Mail list logo
