On 03.08.2018 15: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.i
On Fri, Aug 03, 2018 at 03:18:18PM +0200, Kamil Rytarowski wrote:
> The change was indicating to the compiler that code is safe, without
> changing the algorithm.
I don't get why.
Martin
On 03.08.2018 15:20, Martin Husemann wrote:
> On Fri, Aug 03, 2018 at 03:18:18PM +0200, Kamil Rytarowski wrote:
>> The change was indicating to the compiler that code is safe, without
>> changing the algorithm.
>
> I don't get why.
>
> Martin
>
Overflow (underflow) of an unsigned value is defin
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
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: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 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.
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 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 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
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 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
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 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
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 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: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 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 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 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
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
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
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
Module Name:src
Committed By: christos
Date: Tue May 14 16:22:09 UTC 2019
Modified Files:
src/external/bsd/jemalloc/include/jemalloc/internal:
jemalloc_internal_defs.h
Log Message:
Hack around clang powerpc tls_model("initial-exec") pic issue; this is gross.
Module Name:src
Committed By: christos
Date: Tue May 14 16:22:09 UTC 2019
Modified Files:
src/external/bsd/jemalloc/include/jemalloc/internal:
jemalloc_internal_defs.h
Log Message:
Hack around clang powerpc tls_model("initial-exec") pic issue; this is gross.
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
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
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 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?
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 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 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 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 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 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
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 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:
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 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 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: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 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 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 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 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 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 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 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
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 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
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
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
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?
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 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
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 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
>>>
>>>
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
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
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
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 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 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
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
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
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
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
"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
Module Name:src
Committed By: christos
Date: Thu Aug 19 12:13:37 UTC 2021
Modified Files:
src/external/bsd/openldap/dist/libraries/libldap: gssapi.c
Log Message:
Fix debugging formats
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 \
src/external/bsd/open
Module Name:src
Committed By: christos
Date: Thu Aug 19 12:13:37 UTC 2021
Modified Files:
src/external/bsd/openldap/dist/libraries/libldap: gssapi.c
Log Message:
Fix debugging formats
To generate a diff of this commit:
cvs rdiff -u -r1.4 -r1.5 \
src/external/bsd/open
Module Name:src
Committed By: rillig
Date: Mon Sep 6 17:34:33 UTC 2021
Modified Files:
src/external/bsd/openldap/dist/libraries/libldap: tls2.c
Log Message:
libldap: fix undefined behavior in ldap_int_tls_connect
The function isdigit must not be called with 'char' as arg
Module Name:src
Committed By: rillig
Date: Mon Sep 6 17:34:33 UTC 2021
Modified Files:
src/external/bsd/openldap/dist/libraries/libldap: tls2.c
Log Message:
libldap: fix undefined behavior in ldap_int_tls_connect
The function isdigit must not be called with 'char' as arg
Module Name:src
Committed By: he
Date: Wed Oct 6 09:06:21 UTC 2021
Modified Files:
src/external/bsd/pam-u2f/dist/pamu2fcfg: pamu2fcfg.c
Log Message:
Add what must be an overlooked newline in the normal output.
To generate a diff of this commit:
cvs rdiff -u -r1.1.1.2 -r
Module Name:src
Committed By: he
Date: Wed Oct 6 09:06:21 UTC 2021
Modified Files:
src/external/bsd/pam-u2f/dist/pamu2fcfg: pamu2fcfg.c
Log Message:
Add what must be an overlooked newline in the normal output.
To generate a diff of this commit:
cvs rdiff -u -r1.1.1.2 -r
Module Name:src
Committed By: mrg
Date: Fri Oct 4 09:19:19 UTC 2019
Modified Files:
src/external/bsd/atf/dist/atf-sh: atf-check.cpp
Log Message:
give a catch() a variable. gcc 8 is picky:
atf-check.cpp:221:23: error: catching polymorphic type 'class
std::runtime_error'
Module Name:src
Committed By: mrg
Date: Fri Oct 4 09:19:19 UTC 2019
Modified Files:
src/external/bsd/atf/dist/atf-sh: atf-check.cpp
Log Message:
give a catch() a variable. gcc 8 is picky:
atf-check.cpp:221:23: error: catching polymorphic type 'class
std::runtime_error'
Module Name:src
Committed By: christos
Date: Tue Oct 8 20:02:45 UTC 2019
Modified Files:
src/external/bsd/iscsi/dist/src/lib: target.c
Log Message:
grow the buffer.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/external/bsd/iscsi/dist/src/lib/target.c
Module Name:src
Committed By: christos
Date: Tue Oct 8 20:02:45 UTC 2019
Modified Files:
src/external/bsd/iscsi/dist/src/lib: target.c
Log Message:
grow the buffer.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/external/bsd/iscsi/dist/src/lib/target.c
Module Name:src
Committed By: joerg
Date: Wed Nov 13 22:34:50 UTC 2019
Removed Files:
src/external/bsd/llvm/dist/llvm-configure: configure run-autoconf
src/external/bsd/llvm/dist/llvm-configure/autoconf: AutoRegen.sh
ExportMap.map LICENSE.TXT README.TXT
Module Name:src
Committed By: joerg
Date: Wed Nov 13 22:34:50 UTC 2019
Removed Files:
src/external/bsd/llvm/dist/llvm-configure: configure run-autoconf
src/external/bsd/llvm/dist/llvm-configure/autoconf: AutoRegen.sh
ExportMap.map LICENSE.TXT README.TXT
Module Name:src
Committed By: uwe
Date: Mon Jun 17 15:26:09 UTC 2019
Modified Files:
src/external/bsd/nvi/dist/docs/vitut: vi.in
Log Message:
Fix unnamed/named edito.
>From adr at sdf dot org.
To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1 -r1.2 src/external/b
Module Name:src
Committed By: uwe
Date: Mon Jun 17 15:26:09 UTC 2019
Modified Files:
src/external/bsd/nvi/dist/docs/vitut: vi.in
Log Message:
Fix unnamed/named edito.
>From adr at sdf dot org.
To generate a diff of this commit:
cvs rdiff -u -r1.1.1.1 -r1.2 src/external/b
Module Name:src
Committed By: rillig
Date: Wed Jul 10 19:37:41 UTC 2024
Modified Files:
src/external/bsd/atf/dist/atf-c: macros.h
Log Message:
atf-c: detect accidental '=' in assertion condition
Seen several times in tests/libc/c063.
To generate a diff of this commit:
c
Module Name:src
Committed By: rillig
Date: Wed Jul 10 19:37:41 UTC 2024
Modified Files:
src/external/bsd/atf/dist/atf-c: macros.h
Log Message:
atf-c: detect accidental '=' in assertion condition
Seen several times in tests/libc/c063.
To generate a diff of this commit:
c
"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
Module Name:src
Committed By: kamil
Date: Fri Aug 16 23:07:20 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: common.mk
Log Message:
Set NODEBUG for LLVM sanitizers
The sanitizers are special purpose piece of software that needs customized
buil
Module Name:src
Committed By: kamil
Date: Fri Aug 16 23:07:20 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: common.mk
Log Message:
Set NODEBUG for LLVM sanitizers
The sanitizers are special purpose piece of software that needs customized
buil
Module Name:src
Committed By: kamil
Date: Fri Aug 23 19:26:03 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/safestack-m32:
Makefile
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/safestack-m64:
Makefile
Module Name:src
Committed By: kamil
Date: Fri Aug 23 19:26:03 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/safestack-m32:
Makefile
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/safestack-m64:
Makefile
Module Name:src
Committed By: kamil
Date: Fri Aug 30 23:36:41 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/asan-m64: Makefile
src/external/bsd/compiler_rt/lib/clang/lib/
Module Name:src
Committed By: kamil
Date: Fri Aug 30 23:36:41 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: syms.mk
src/external/bsd/compiler_rt/lib/clang/lib/netbsd/asan-m64: Makefile
src/external/bsd/compiler_rt/lib/clang/lib/
Module Name:src
Committed By: kamil
Date: Tue Sep 3 03:04:31 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: common.mk
Log Message:
Set NOLIBCSANITIZER for LLVM sanitizer runtimes
Do not sanitize sanitizer runtimes.
To generate a diff of thi
Module Name:src
Committed By: kamil
Date: Tue Sep 3 03:04:31 UTC 2019
Modified Files:
src/external/bsd/compiler_rt/lib/clang/lib/netbsd: common.mk
Log Message:
Set NOLIBCSANITIZER for LLVM sanitizer runtimes
Do not sanitize sanitizer runtimes.
To generate a diff of thi
Modified Files:
src/external/bsd/bind/dist/bin/named: server.c
Log Message:
Don't log if "." is not writable. In the chrooted environment this is
"/var/chroot/named", and there is no reason whatsoever for this to be
writable!
this seems bogus to me.
this check seem
In article <22061.1240544...@splode.eterna.com.au>,
matthew green wrote:
>
> Modified Files:
> src/external/bsd/bind/dist/bin/named: server.c
>
> Log Message:
> Don't log if "." is not writable. In the chrooted environment this is
> "/var/chroot/named", and there is no reason
In article <22061.1240544...@splode.eterna.com.au>,
matthew green wrote:
>
> Modified Files:
>src/external/bsd/bind/dist/bin/named: server.c
>
> Log Message:
> Don't log if "." is not writable. In the chrooted environment this is
> "/var/chroot/named"
On Apr 25, 1:31am, m...@eterna.com.au (matthew green) wrote:
-- Subject: re: CVS commit: src/external/bsd/bind/dist/bin/named
|Perhaps you are confusing this directory with /var/chroot/named/etc/namedb?
|
| i'm saying that named should be configured to have this dir as
| the cwd and
chris...@zoulas.com (Christos Zoulas) writes:
> And I don't really see the need to make the whole namedb directory owned
> by named. Even the pri directory does not need to be writable by named.
The only time named really needs to write to the config dir is for
dynamic update. The only other time
On Wed, Oct 28, 2009 at 09:08:45AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Oct 28 13:08:45 UTC 2009
>
> Modified Files:
> src/external/bsd/am-utils/dist/include: am_defs.h
>
> Log Message:
> Deal with errno correctly. Fixed better upstr
On Oct 28, 2:17pm, jo...@britannica.bec.de (Joerg Sonnenberger) wrote:
-- Subject: Re: CVS commit: src/external/bsd/am-utils/dist/include
| On Wed, Oct 28, 2009 at 09:08:45AM -0400, Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date:
901 - 1000 of 1065 matches
Mail list logo
