In article ,
Roland Illig wrote:
>Am 10.07.2024 um 03:12 schrieb Christos Zoulas:
>
>src/tests/lib/libc/c063/t_fchmodat.c
>> -ATF_REQUIRE(st.st_mode = 0600);
>> +ATF_REQUIRE(st.st_mode == 0600);
>
>Should we do something to detect bugs like these mechanically?
>
>ATF_REQUIRE(cond) current
Am 10.07.2024 um 03:12 schrieb Christos Zoulas:
src/tests/lib/libc/c063/t_fchmodat.c
> - ATF_REQUIRE(st.st_mode = 0600);
> + ATF_REQUIRE(st.st_mode == 0600);
Should we do something to detect bugs like these mechanically?
ATF_REQUIRE(cond) currently expands to "if (!(cond))", and I guess
Date:Mon, 1 Aug 2022 18:55:15 +0300
From:Valery Ushakov
Message-ID:
| The test uses __clone(), not clone() and a followup fix made __clone()
| visible under plain _NETBSD_SOURCE again - which is the right thing,
| IMO. So this change is not necessary (the test
On Mon, Aug 01, 2022 at 15:48:40 +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Mon Aug 1 15:48:40 UTC 2022
>
> Modified Files:
> src/tests/lib/libc/sys: Makefile
>
> Log Message:
> Provide _GNU_SOURCE for t_clone now that is required to make clone()
> vi
On Sat, Jun 27, 2020 at 10:39:08AM +, m...@netbsd.org wrote:
> > Add the default TNF copyright (2005), cf. PR misc/55419.
>
> I don't think we can generally do this. Can you clarify if you discussed
> this with the author in commit messages?
Well, the committer is christos, and I doubt he car
On Sat, Jun 27, 2020 at 10:19:43AM +, Jukka Ruohonen wrote:
> Module Name: src
> Committed By: jruoho
> Date: Sat Jun 27 10:19:43 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/stdlib: t_mbtowc.c
>
> Log Message:
> Add the default TNF copyright (2005), cf. PR misc/55419.
>
Committed. Thank you for your comment!
rin
On 2020/06/22 20:09, Kamil Rytarowski wrote:
On 22.06.2020 04:51, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Mon Jun 22 02:51:07 UTC 2020
Modified Files:
src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_
On 22.06.2020 04:51, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Mon Jun 22 02:51:07 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_signal_wait.h t_ptrace_wait.h
>
> Log Message:
> Turn trigger_fpe() back to integer division by zero for a whil
On 2020/06/17 17:42, Rin Okuyama wrote:
Now, all *_crash_fpe tests pass for powerpc, and nothing changes for amd64
at least.
Here, powerpc means powerpc/oea, more specifically Mac mini G4.
At the moment, fenv.h doesn't work correctly on booke and ibm4xx, where FPU
is emulated in software. For
On Sat, Jun 06, 2020 at 06:11:21PM +, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Sat Jun 6 18:11:21 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_lwp_create.c
>
> Log Message:
> Add a test case to ensure that _lwp_create() fails with t
On 15.05.2020 00:43, Taylor R Campbell wrote:
>> Date: Thu, 14 May 2020 23:36:28 +0200
>> From: Kamil Rytarowski
>>
>> If a signal would not reach the child process (as it is ignored or
>> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
>> checked, it's the design in UNIX to o
> Date: Thu, 14 May 2020 23:36:28 +0200
> From: Kamil Rytarowski
>
> If a signal would not reach the child process (as it is ignored or
> masked+SA_IGNOREd) and it is not a crash signal, it is dropped. As I
> checked, it's the design in UNIX to overlook SIGCHLD signals in UNIX.
> Race free signal
On Thu, May 14, 2020 at 11:36:28PM +0200, Kamil Rytarowski wrote:
> On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Thu May 14 19:21:35 UTC 2020
> >
On 14.05.2020 23:02, Joerg Sonnenberger wrote:
> On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Thu May 14 19:21:35 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>>
>>
On Thu, May 14, 2020 at 07:21:35PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Thu May 14 19:21:35 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_fork_wait.h
>
> Log Message:
> Ignore interception of the SIGCHLD signals.
>
> SIG
Date:Mon, 11 May 2020 13:47:45 +0200
From:Kamil Rytarowski
Message-ID: <54178983-82d1-df3d-fd54-549a6c73f...@gmx.com>
| The only purpose of the test is to check whether misaligned program
| counter can crash the kernel (it can for NetBSD/sparc). Later, if a
| pr
On 11.05.2020 13:35, Robert Elz wrote:
> Date:Mon, 11 May 2020 11:03:15 +
> From:"Kamil Rytarowski"
> Message-ID: <2020050315.54b13f...@cvs.netbsd.org>
>
> | Do not fail when trying to kill a dying process
> |
> | A dying process can disappear for a whil
Date:Mon, 11 May 2020 11:03:15 +
From:"Kamil Rytarowski"
Message-ID: <2020050315.54b13f...@cvs.netbsd.org>
| Do not fail when trying to kill a dying process
|
| A dying process can disappear for a while. Rather than aborting, retry
| sending SIGKILL to
On 24.04.2020 05:25, Jason R Thorpe wrote:
> Module Name: src
> Committed By: thorpej
> Date: Fri Apr 24 03:25:20 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_x86_wait.h
>
> Log Message:
> Update for new LWP behavior -- as of 9.99.59, the LWP ID o
In article <5e528f7a-147a-23e7-46da-6b02d76e5...@gmx.com>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>On 07.03.2020 15:53, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Sat Mar 7 14:53:14 UTC 2020
>>
>> Modified Files:
>> src/
On 07.03.2020 15:53, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat Mar 7 14:53:14 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_wait.c t_ptrace_wait.h
>
> Log Message:
> Try to fix the build. This is why all those inlines should r
On 24.02.2020 20:32, Christos Zoulas wrote:
> In article <20200221222550.325a6f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Fri Feb 21 22:25:50 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/ge
In article <20200221222550.325a6f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Fri Feb 21 22:25:50 UTC 2020
>
>Modified Files:
> src/tests/lib/libc/gen: t_siginfo.c
>
>Log Message:
>Mark division by 0 as expected in sigf
On 24.02.2020 20:29, Christos Zoulas wrote:
> In article <20200222191457.87687f...@cvs.netbsd.org>,
> Kamil Rytarowski wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 22 19:14:57 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/ge
In article <20200222191457.87687f...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Feb 22 19:14:57 UTC 2020
>
>Modified Files:
> src/tests/lib/libc/gen: Makefile
>
>Log Message:
>Update t_siginfo.c build rules
>
>Add log
On 21.02.2020 23:53, matthew green wrote:
>> Disable ubsan instrumentation on the operation.
>
> +#if defined(__clang__)
> +__attribute__((no_sanitize("undefined")))
> +#else
> +__attribute__((no_sanitize_undefined))
> +#endif
>
> can we get a __disable_sanitizer or something i cdefs.h?
>
>
> .
> Disable ubsan instrumentation on the operation.
+#if defined(__clang__)
+__attribute__((no_sanitize("undefined")))
+#else
+__attribute__((no_sanitize_undefined))
+#endif
can we get a __disable_sanitizer or something i cdefs.h?
.mrg.
On 18.02.2020 16:57, Christos Zoulas wrote:
> In article <20200213152742.081a9f...@cvs.netbsd.org>,
> MichaŠGórny wrote:
>> -=-=-=-=-=-
>>
>> Module Name: src
>> Committed By:mgorny
>> Date:Thu Feb 13 15:27:41 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/sy
In article <20200213152742.081a9f...@cvs.netbsd.org>,
MichaŠGórny wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: mgorny
>Date: Thu Feb 13 15:27:41 UTC 2020
>
>Modified Files:
> src/tests/lib/libc/sys: t_ptrace_wait.c
>
>Log Message:
>Enable combined breakpoint, watchp
In article <20200213114904.ga30...@bec.de>,
Joerg Sonnenberger wrote:
>On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote:
>> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> > Module Name: src
>> > Committed By: christos
>> > Date: Thu F
In article <20200213095019.ga28...@bec.de>,
Joerg Sonnenberger wrote:
>On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Feb 13 02:53:46 UTC 2020
>>
>> Modified Files:
>> src/tests/lib/libc/sys:
On Thu, Feb 13, 2020 at 10:50:19AM +0100, Joerg Sonnenberger wrote:
> On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Thu Feb 13 02:53:46 UTC 2020
> >
> > Modified Files:
> > src/tests/lib/lib
On Wed, Feb 12, 2020 at 09:53:46PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Feb 13 02:53:46 UTC 2020
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_x86_wait.h
>
> Log Message:
> Turn off optimization on a function which contains
On 01.07.2019 14:59, Robert Elz wrote:
> Date:Mon, 1 Jul 2019 11:55:57 +0200
> From:Joerg Sonnenberger
> Message-ID: <20190701095557.ga55...@bec.de>
>
> | On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:
>
> | > Cast note_hdr.n_namesz to ssize_t
Date:Mon, 1 Jul 2019 11:55:57 +0200
From:Joerg Sonnenberger
Message-ID: <20190701095557.ga55...@bec.de>
| On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:
| > Cast note_hdr.n_namesz to ssize_t through size_t to avoid potential
| > signedness bi
On Mon, Jul 01, 2019 at 02:04:38AM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Mon Jul 1 02:04:38 UTC 2019
>
> Modified Files:
> src/tests/lib/libc/sys: t_ptrace_wait.c
>
> Log Message:
> Avoid GCC warning on NetBSD/i386
>
> Cast note_hdr.n_nam
On Feb 28, 1:05am, is...@pastel-flower.jp (Tetsuya Isaki) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/atomic
| At Wed, 27 Feb 2019 10:32:11 -0500,
| Christos Zoulas wrote:
| > Module Name:src
| > Committed By: christos
| > Date: Wed Feb 27 15:32:11
At Wed, 27 Feb 2019 10:32:11 -0500,
Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Feb 27 15:32:11 UTC 2019
>
> Modified Files:
> src/tests/lib/libc/atomic: t___sync_and.c
>
> Log Message:
> Make the _and_and_ have-nots compile.
Sorry for build brea
On 04.02.2019 09:50, Robert Elz wrote:
> Date:Mon, 4 Feb 2019 05:02:46 +0100
> From:Kamil Rytarowski
> Message-ID: <2eadaf71-d7d7-c285-bdec-78ddcd3a5...@gmx.com>
>
>
> | If GCC is fine with it, we could try raise(!!(a * b) ? SIGSEGV : SIGBUS);=
>
> That's a kind o
Date:Mon, 4 Feb 2019 05:02:46 +0100
From:Kamil Rytarowski
Message-ID: <2eadaf71-d7d7-c285-bdec-78ddcd3a5...@gmx.com>
| If GCC is fine with it, we could try raise(!!(a * b) ? SIGSEGV : SIGBUS);=
That's a kind of odd way of saying (a * b) != 0 ? ...
kre
On 04.02.2019 04:10, matthew green wrote:
> Module Name: src
> Committed By: mrg
> Date: Mon Feb 4 03:10:33 UTC 2019
>
> Modified Files:
> src/tests/lib/libc/misc: Makefile t_ubsan.c
>
> Log Message:
> - revert previous to t_ubsan.c, it is desired behaviour. from kamil.
> - use -
> On May 24, 2018, at 10:45 PM, Kamil Rytarowski wrote:
>
> Fixed!
Confirmed! Thanks!
-- thorpej
On 24.05.2018 06:17, Jason Thorpe wrote:
> This change seems to have broken building on 32-bit platforms (certainly at
> least for 32-bit ARM):
>
> # compile sys/t_ptrace_wait.o
> /nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2 -std=gnu99-Wall
> -Wstrict-prototypes -Wmissing-prototypes
This change seems to have broken building on 32-bit platforms (certainly at
least for 32-bit ARM):
# compile sys/t_ptrace_wait.o
/nbsd/tools/bin/armv6--netbsdelf-eabihf-gcc -O2 -std=gnu99-Wall
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-sign-compare
-Wsystem-headers
On 27.02.2018 12:48, Valery Ushakov wrote:
> On Tue, Feb 27, 2018 at 11:15:53 +, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Tue Feb 27 11:15:53 UTC 2018
>>
>> Modified Files:
>> src/tests/lib/libc/sys: t_ucontext.c
>>
>> Log Message
On Tue, Feb 27, 2018 at 11:15:53 +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Tue Feb 27 11:15:53 UTC 2018
>
> Modified Files:
> src/tests/lib/libc/sys: t_ucontext.c
>
> Log Message:
> Make the t_ucontext.c test more portable
>
> Cast _UC_MACHIN
Date:Sat, 2 Dec 2017 00:09:29 +0100
From:Joerg Sonnenberger
Message-ID: <20171201230929.ga13...@britannica.bec.de>
| This is *not* true. With C11 the standard is very explicit that return
| must discard excessive precision. Even before, it was implied that there
On Fri, Dec 01, 2017 at 01:08:35AM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Fri Dec 1 01:08:35 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/locale: t_sprintf.c
>
> Log Message:
> Since the C standard allows for intermediate floating results to c
Date:Thu, 30 Nov 2017 23:09:07 +0100
From:Manuel Bouyer
Message-ID: <20171130220907.ga2...@antioche.eu.org>
| Shouldn't it be made Xfail on i386 in this case ?
I don't think so, especially not now the problem is understood - it is
trivial to make it work on i386, t
On Thu, Nov 30, 2017 at 06:16:10AM +0700, Robert Elz wrote:
> Date:Wed, 29 Nov 2017 16:51:56 +
> From:Taylor R Campbell
>
> Message-ID: <20171129165637.6fa4960...@jupiter.mumble.net>
>
> | This is starting to smell like a compiler bug in fp correctness...but
>
Date:Wed, 29 Nov 2017 16:51:56 +
From:Taylor R Campbell
Message-ID: <20171129165637.6fa4960...@jupiter.mumble.net>
| This is starting to smell like a compiler bug in fp correctness...but
| I'm out of time to diagnose it further.
In case anyone missed it, the
> Date: Wed, 29 Nov 2017 09:14:26 +0100
> From: Martin Husemann
>
> (gdb) info float
> R7: Valid 0xc00cc0e6b7318fc50481 -12345.678979
> =>R6: Valid 0xc00cc0e6b7318fc50800 -12345.678979
> R5: Empty 0xc00cc0e6b7318fc50800
> [...]
> Control Word:0x037f
For the gcc 5.5 version:
30 if (!(d == t->double_value)) {
(gdb) x/16i $pc
=> 0x804887c : fldl 0x4(%ebx)
0x804887f : fucomp %st(2)
0x8048881 : fnstsw %ax
0x8048883 : sahf
0x8048884 : jp 0x8048891
0x8048886 : jne0x8048891
and
On Wed, Nov 29, 2017 at 09:03:50AM +0100, Martin Husemann wrote:
> On Wed, Nov 29, 2017 at 06:12:02AM +, Taylor R Campbell wrote:
> > (My guess is that there's something screwy with i387 long doubles, but
> > I don't have a good guess about where that screwiness might be
> > happening without s
On Wed, Nov 29, 2017 at 06:12:02AM +, Taylor R Campbell wrote:
> (My guess is that there's something screwy with i387 long doubles, but
> I don't have a good guess about where that screwiness might be
> happening without single-stepping through it.)
My blame is on qemu.
I added the missing pr
Date:Wed, 29 Nov 2017 06:12:02 +
From:Taylor R Campbell
Message-ID: <20171129061642.e8dcb60...@jupiter.mumble.net>
| That's pretty interesting!
That is what I thought, it was certainly not what I expected.
| Can you reproduce it in a small isolated program l
> Date: Wed, 29 Nov 2017 11:41:58 +0700
> From: Robert Elz
>
> OK, got my i386 test setup (a Xen DomU) built & running, the updated
> test failed (as it always failed on i386 before I added the epsilon
> test, which is #if 0'd out now) the results are ...
>
> strto: [0.002429s] Failed:
> /r
Date:Wed, 29 Nov 2017 02:49:02 +
From:Taylor R Campbell
Message-ID: <20171129025342.734f860...@jupiter.mumble.net>
| If it turns out that this
| test is legitimately wrong on VAX, we can conditionalize it for VAX.
It wasn't whether it is going to be wrong the
Date:Tue, 28 Nov 2017 15:09:56 +
From:Taylor R Campbell
Message-ID: <20171128151435.9bbae60...@jupiter.mumble.net>
| Can you please put it back to an exact equality test and report the
| mismatched values in the output, with %a rather than (or in addition
|
> Date: Wed, 29 Nov 2017 05:37:56 +0700
> From: Robert Elz
>
> I think that conclusion had been reached already (not by me...) but that's
> "Under IEEE 754-2008" right? What about architectures that don't use IEEE
> floats? This test should not be assuming that - we still support vax right?
>
Date:Tue, 28 Nov 2017 15:34:19 +0100
From:Joerg Sonnenberger
Message-ID: <20171128143418.ga8...@britannica.bec.de>
| Hidding things until then doesn't actually fix something.
No, it doesn't, but when I made the change I wasn't hiding anything,
just doing what I tho
> Date: Tue, 28 Nov 2017 05:32:45 +0700
> From: Robert Elz
>
> Way back when I first learned floating point programming (something I
> have done astonishingly little of in the intervening decades) I was
> told it was *always* wrong to compare floats for exact equality - but
> of course, that was
On Tue, Nov 28, 2017 at 05:32:45AM +0700, Robert Elz wrote:
> Date:Mon, 27 Nov 2017 18:44:38 +0100
> From:Joerg Sonnenberger
> Message-ID: <20171127174438.ga20...@britannica.bec.de>
>
> | Parsing a string constant is a well-defined
> | operation with precise resul
Date:Mon, 27 Nov 2017 18:44:38 +0100
From:Joerg Sonnenberger
Message-ID: <20171127174438.ga20...@britannica.bec.de>
| Parsing a string constant is a well-defined
| operation with precise result. A cross-compiler that doesn't do that
| correctly is simply broken.
On Fri, Nov 24, 2017 at 09:30:43PM +, Robert Elz wrote:
> Module Name: src
> Committed By: kre
> Date: Fri Nov 24 21:30:43 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/locale: t_sprintf.c
>
> Log Message:
> When comparing doubles (any floating point values) which have been
help
On Tue, May 23, 2017 at 7:01 PM, Christos Zoulas
wrote:
> Module Name:src
> Committed By: christos
> Date: Tue May 23 16:01:46 UTC 2017
>
> Modified Files:
> src/tests/lib/libc/sys: t_mincore.c
>
> Log Message:
> Add the error in syscall failure.
>
>
> To generate a
Module Name:src
Committed By: martin
Date: Fri Mar 24 08:18:27 UTC 2017
Modified Files:
src/tests/lib/libc/sys: t_mprotect.c
Log Message:
Do not toggle global security.pax.mprotect state in an attempt to
activate it for the current process. It does not work and tests shou
Should address PR bin/51869
On Sat, 14 Jan 2017, Paul Goyette wrote:
Module Name:src
Committed By: pgoyette
Date: Sat Jan 14 03:59:58 UTC 2017
Modified Files:
src/tests/lib/libc/sys: Makefile
Log Message:
Set FILESBUILD=yes to actually run the creation script for the f
On Fri, 26 Aug 2016 15:46:55 +1000
matthew green wrote:
> > Modified Files:
> > src/tests/lib/libc/net/getaddrinfo: Makefile
> > src/tests/lib/libc/regex: Makefile
> >
> > Log Message:
> > Replace MKMAN with NOMAN as suggested by christos@. Allows
> > userland to build when building man
"D'Arcy J.M. Cain" writes:
> Module Name: src
> Committed By: darcy
> Date: Fri Aug 26 01:31:43 UTC 2016
>
> Modified Files:
> src/tests/lib/libc/net/getaddrinfo: Makefile
> src/tests/lib/libc/regex: Makefile
>
> Log Message:
> Replace MKMAN with NOMAN as suggested by christo
Date:Tue, 9 Aug 2016 12:02:44 +
From:"Robert Elz"
Message-ID: <20160809120244.9f9d0f...@cvs.netbsd.org>
Ignore this part ...
| Note that NetBSD mlock(2) talks about EINVAL for cases where the length
| parameter is negative ... but that is a size_t - good luck
In article <20160718140933.gb10...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Jul 18, 2016 at 08:17:39AM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Jul 18 12:17:39 UTC 2016
>>
>> Modified Files:
>> src/tests/lib
On Mon, Jul 18, 2016 at 08:17:39AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Jul 18 12:17:39 UTC 2016
>
> Modified Files:
> src/tests/lib/libc/tls: Makefile
>
> Log Message:
> Not designed for PIE
Huh? The only test case that doesn't sup
On Oct 14, 12:31am, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| Well also there is the bit thats says
|
|
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_13_01
|
| When pattern matching is used where
On Mon, Oct 13, 2014 at 2:26 PM, Christos Zoulas wrote:
> On Oct 13, 2:23pm, jus...@specialbusservice.com (Justin Cormack) wrote:
> -- Subject: Re: CVS commit: src/tests/lib/libc/gen
>
> | You can have a ] by having it as the first character that is made explicit.
> | And if the /
On Oct 13, 2014 2:13 PM, "Christos Zoulas" wrote:
>
> On Oct 13, 11:29am, jus...@specialbusservice.com (Justin Cormack) wrote:
> -- Subject: Re: CVS commit: src/tests/lib/libc/gen
>
> | Not sure about this. See
> |
http://pubs.opengroup.org/onlinepubs/009695
On Oct 13, 2:23pm, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| You can have a ] by having it as the first character that is made explicit.
| And if the / is not special then that is no problem either.
Yes, '/' is the probl
On Oct 13, 11:29am, jus...@specialbusservice.com (Justin Cormack) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/gen
| Not sure about this. See
|
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap09.html#tag_09_03_05
|
| "The special characters '.'
On Sun, Oct 12, 2014 at 11:33 PM, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Sun Oct 12 22:33:41 UTC 2014
>
> Modified Files:
> src/tests/lib/libc/gen: t_fnmatch.c
>
> Log Message:
> You need double the number of backslashes in a pattern, sinc
On Fri, Jan 10, 2014 at 08:47:01PM +0200, Jukka Ruohonen wrote:
> I got a bit lost with Jelinek's reply above. Aren't those tests specifically
> for NetBSD's ssp(3), a.k.a. -D_FORTIFY_SOURCE=2 and not -fstack-protector?
Yes, the ticket could be improved, but actually the behaviour is
identical. As
On Fri, Jan 10, 2014 at 10:45:34AM +, Martin Husemann wrote:
> Module Name: src
> Committed By: martin
> Date: Fri Jan 10 10:45:34 UTC 2014
>
> Modified Files:
> src/tests/lib/libc/ssp: t_ssp.sh
>
> Log Message:
> In the strcat test, smash the stack more severely (this all may
On Thu, Jan 09, 2014 at 09:42:25AM +, Justin Cormack wrote:
> On Thu, Jan 9, 2014 at 2:18 AM, Christos Zoulas wrote:
> > Module Name:src
> > Committed By: christos
> > Date: Thu Jan 9 02:18:10 UTC 2014
> >
> > Modified Files:
> > src/tests/lib/libc/net: Makefile h_dns_
On Thu, Jan 9, 2014 at 2:18 AM, Christos Zoulas wrote:
> Module Name:src
> Committed By: christos
> Date: Thu Jan 9 02:18:10 UTC 2014
>
> Modified Files:
> src/tests/lib/libc/net: Makefile h_dns_server.c h_hostent.c
> t_hostent.sh
> Added Files:
> src/t
On Fri, Oct 25, 2013 at 02:50:56AM +, David Holland wrote:
> In some sense I'd rather these tests ran by setting up two VMs (rumpy
> or otherwise), one with bind and one with the resolver. Among other
> things it would be more likely to produce consistent test results.
...but, as I meant to
On Thu, Oct 24, 2013 at 01:24:34PM -0700, Paul Goyette wrote:
> >-- Subject: Re: CVS commit: src/tests/lib/libc/net
> >
> >| Maybe run ifconfig and see if there are any interfaces, other than lo0,
> >| in UP state. If not, then the test case can return a skip status.
On Thu, 24 Oct 2013, Christos Zoulas wrote:
On Oct 24, 12:32pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/net
| Maybe run ifconfig and see if there are any interfaces, other than lo0,
| in UP state. If not, then the test case can return a skip
On Oct 24, 12:32pm, p...@whooppee.com (Paul Goyette) wrote:
-- Subject: Re: CVS commit: src/tests/lib/libc/net
| Maybe run ifconfig and see if there are any interfaces, other than lo0,
| in UP state. If not, then the test case can return a skip status.
I think that it should be a builtin test
Maybe run ifconfig and see if there are any interfaces, other than lo0,
in UP state. If not, then the test case can return a skip status.
On Thu, 24 Oct 2013, Christos Zoulas wrote:
In article <20131024162426.ga7...@asim.lip6.fr>,
Manuel Bouyer wrote:
On Thu, Oct 24, 2013 at 03:04:56PM +0
In article <20131024162426.ga7...@asim.lip6.fr>,
Manuel Bouyer wrote:
>On Thu, Oct 24, 2013 at 03:04:56PM +, Taylor R Campbell wrote:
>> It seems to me that this is an entirely reasonable setup, and that the
>> tests ought not to depend on a connection to the internet.
>
>Seconded. Tests are
On Thu, Oct 24, 2013 at 03:04:56PM +, Taylor R Campbell wrote:
> It seems to me that this is an entirely reasonable setup, and that the
> tests ought not to depend on a connection to the internet.
Seconded. Tests are failing on the xen testbed too, and I wondered how
they could work in a setup
On Thu, Oct 24, 2013 at 03:04:56PM +, Taylor R Campbell wrote:
> It seems to me that this is an entirely reasonable setup, and that the
> tests ought not to depend on a connection to the internet.
Indeed, another option is to rumpify these tests (and not rely on external
machines). Not trivial
Date: Thu, 24 Oct 2013 08:01:51 -0700 (PDT)
From: Paul Goyette
Although my host machine has full connectivity, including IPv6, the
tests are run under qemu. The qemu virtual machine has a default nic
available, but there is nothing in the test-bed set-up to initialize
anythi
On Thu, 24 Oct 2013, Martin Husemann wrote:
On Thu, Oct 24, 2013 at 07:37:13AM -0700, Paul Goyette wrote:
No cache info, only my provider's name-servers:
Can you trace with tcpdump while the test fails?
From an off-line exchange with Martin, it seems that the failures in my
test-bed are l
On Thu, Oct 24, 2013 at 07:37:13AM -0700, Paul Goyette wrote:
> No cache info, only my provider's name-servers:
Can you trace with tcpdump while the test fails?
Martin
On Thu, 24 Oct 2013, Martin Husemann wrote:
On Thu, Oct 24, 2013 at 07:18:55AM -0700, Paul Goyette wrote:
Yes, host reports everything:
# host sixthavenue.astron.com
sixthavenue.astron.com has address 38.117.134.6
sixthavenue.astron.com has IPv6 address
2620:106:3003:1f00:2e0:81ff:fe2f:e5d7
si
On Thu, Oct 24, 2013 at 07:18:55AM -0700, Paul Goyette wrote:
> Yes, host reports everything:
>
> # host sixthavenue.astron.com
> sixthavenue.astron.com has address 38.117.134.6
> sixthavenue.astron.com has IPv6 address
> 2620:106:3003:1f00:2e0:81ff:fe2f:e5d7
> sixthavenue.astron.com mail is hand
On Thu, 24 Oct 2013, Martin Husemann wrote:
On Thu, Oct 24, 2013 at 07:04:41AM -0700, Paul Goyette wrote:
Looks normal to me:
It is lacking all the IPv6 stuff. Does "host" list both addresses?
Yes, host reports everything:
# host sixthavenue.astron.com
sixthavenue.astron.com has address 38
On Thu, Oct 24, 2013 at 07:04:41AM -0700, Paul Goyette wrote:
> Looks normal to me:
It is lacking all the IPv6 stuff. Does "host" list both addresses?
Martin
On Thu, 24 Oct 2013, Martin Husemann wrote:
On Thu, Oct 24, 2013 at 06:40:49AM -0700, Paul Goyette wrote:
All of the tests related to "sixthavenue.astron.com" are still failing
in my amd64 test-bed[1]. Sources are updated (via anoncvs) and are
current as of 2013-10-23 23:20:04, and the build w
On Thu, Oct 24, 2013 at 06:40:49AM -0700, Paul Goyette wrote:
> All of the tests related to "sixthavenue.astron.com" are still failing
> in my amd64 test-bed[1]. Sources are updated (via anoncvs) and are
> current as of 2013-10-23 23:20:04, and the build was successfully done
> using 'build.sh
1 - 100 of 168 matches
Mail list logo
