Previously, fakeroot would not exit if a process outlived the original
process started by settrans. This caused bugs like this:
% fakeroot-hurd /bin/sh -c 'sleep 1&' 2>&1 | tee
Fix this by exiting if the last client of fakeroot goes away.
* trans/fakeroot.c (fakeroot_netfs_release_protid): Shu
Quoting Justus Winter (2013-12-18 12:38:31)
> While doing that I discovered that the recent cleanups broke GNU Mach
> when compiled for the Xen target. Two issues were merely missing
> includes, but now it fails like this:
>
> % ./configure --enable-kdb --enable-platform=xen --enable-silent-rules
Justus Winter, le Wed 18 Dec 2013 12:38:32 +0100, a écrit :
> * i386/i386at/kd_event.h: Add missing includes.
Ack.
> ---
> i386/i386at/kd_event.h | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/i386/i386at/kd_event.h b/i386/i386at/kd_event.h
> index f1295cb..9568fa5 100644
> --- a/
* i386/i386at/kd_event.h: Add missing includes.
---
i386/i386at/kd_event.h | 4
1 file changed, 4 insertions(+)
diff --git a/i386/i386at/kd_event.h b/i386/i386at/kd_event.h
index f1295cb..9568fa5 100644
--- a/i386/i386at/kd_event.h
+++ b/i386/i386at/kd_event.h
@@ -26,6 +26,10 @@
#ifndef _KD
Hi :)
I've been playing around with buildbot, the goal is to automatically
produce Debian packages from the upstream git repositories. This is
work in progress.
To that end I took the Debian repositories of Hurd, MIG and GNU Mach
and removed anything that is present in the upstream repositories.
On 18.12.2013 12:00:49, Richard Braun wrote:
> On Wed, Dec 18, 2013 at 11:40:09AM +0100, Marin Ramesa wrote:
> > On 18.12.2013 11:34:03, Richard Braun wrote:
> > > I don't get this warning, can you tell us how you configure GNU
> > > Mach ?
> >
> > --enable-kdb --prefix=
> >
> > But the warning
On Wed, Dec 18, 2013 at 11:40:09AM +0100, Marin Ramesa wrote:
> On 18.12.2013 11:34:03, Richard Braun wrote:
> > I don't get this warning, can you tell us how you configure GNU
> > Mach ?
>
> --enable-kdb --prefix=
>
> But the warning is turned off by:
>
> ipc_port_t notify_port = 0;
>
> in i
On 18.12.2013 11:34:03, Richard Braun wrote:
> On Wed, Dec 18, 2013 at 11:25:36AM +0100, Marin Ramesa wrote:
> > Yes, vou're right. I got confused. But then something else is
> > happening here. When I write the assertion this way:
> >
> > assert((entry == IE_NULL) || ((entry != IE_NULL) ? IE_BI
On Wed, Dec 18, 2013 at 11:25:36AM +0100, Marin Ramesa wrote:
> Yes, vou're right. I got confused. But then something else is happening
> here. When I write the assertion this way:
>
> assert((entry == IE_NULL) || ((entry != IE_NULL) ? IE_BITS_TYPE
> (entry->ie_bits) : TRUE));
>
> GCC stops co
> Marin Ramesa writes:
> On 18.12.2013 10:46:40, Richard Braun wrote:
[...]
>> No, that's wrong. The && and || operators are guaranteed to be
>> evaluated left-to-right, and yield if the first operand compares
>> equal to 0. And that's exactly why this check against NULL is done
>>
On 18.12.2013 11:11:10, Richard Braun wrote:
> The expression is ((a == NULL) || a->something), and I agree it is
> equivalent to !((a != NULL) && !a->something). And again, both the
> && and || operators are guaranteed to be evaluated left-to-right and
> *yield* without evaluating the second opera
On Wed, Dec 18, 2013 at 09:17:49AM +0100, Marin Ramesa wrote:
> The same situation as the previous patch.
Same comment as for the previous patch.
--
Richard Braun
On Wed, Dec 18, 2013 at 09:17:48AM +0100, Marin Ramesa wrote:
> Don't initialize to zero, rather move the initialization of size before
> the break statement. Break on the first iteration should never happen, so the
> position of initialization doesn't matter.
>
> * ipc/mach_debug.c (host_ipc_hash
On Wed, Dec 18, 2013 at 10:55:47AM +0100, Marin Ramesa wrote:
> On 18.12.2013 10:46:40, Richard Braun wrote:
> > No, that's wrong. The && and || operators are guaranteed to be
> > evaluated left-to-right, and yield if the first operand compares
> > equal to 0. And that's exactly why this check aga
On 18.12.2013 10:55:47, Marin Ramesa wrote:
> in order to return TRUE
Sorry, I meant to say in order to return FALSE.
On 18.12.2013 10:46:40, Richard Braun wrote:
> On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
> > Compiler needs to check both !a and !b. In order to evaluate !b it
> > must evaluate b. So when the code path is that when entry is a null
> > pointer, the evaluation of b results in a d
On Wed, Dec 18, 2013 at 10:46:40AM +0100, Richard Braun wrote:
> On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
> > Compiler needs to check both !a and !b. In order to evaluate !b it must
> > evaluate b. So when the code path is that when entry is a null pointer,
> > the evaluation
On Wed, Dec 18, 2013 at 10:37:03AM +0100, Marin Ramesa wrote:
> Compiler needs to check both !a and !b. In order to evaluate !b it must
> evaluate b. So when the code path is that when entry is a null pointer,
> the evaluation of b results in a dereference of a null pointer.
No, that's wrong. Th
On 18.12.2013 10:20:21, Anatoly A. Kazantsev wrote:
> On Wed, 18 Dec 2013 09:17:47 +0100
> Marin Ramesa wrote:
>
> > ...
> > Negation of an
> > OR expression is an AND expression.
> > ...
>
> Maybe I did't get you correctly, but isn't !(a || b) == !a && !b ?
Yes.
> And evaluation of the second
On Wed, 18 Dec 2013 09:17:47 +0100
Marin Ramesa wrote:
> ...
> Negation of an
> OR expression is an AND expression.
> ...
Maybe I did't get you correctly, but isn't !(a || b) == !a && !b ?
And evaluation of the second condition doesn't happen when entry = IE_NULL
--
Regards,
Anatoly
The problem is in this statement:
assert((entry == IE_NULL) || IE_BITS_TYPE(entry->ie_bits));
The macro assert() checks for a negation of this expression. Negation of an
OR expression is an AND expression. In order to evaluate an AND expression,
compiler needs to check both conditions. So it firs
Don't initialize to zero, rather move the initialization of size before
the break statement. Break on the first iteration should never happen, so the
position of initialization doesn't matter.
* ipc/mach_debug.c (host_ipc_hash_info) (size): Don't initialize to zero.
(host_ipc_hash_info) (size): Mo
The same situation as the previous patch.
* vm/vm_debug.c (host_virtual_physical_table_info) (size): Don't initialize to
zero.
(host_virtual_physical_table_info) (size): Move initialization before the break
statement.
---
vm/vm_debug.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-
23 matches
Mail list logo
