On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
> Hello!
>
> We're still being again and again annoyed by programs that use `PATH_MAX'
> unconditionally.
Why stop with this one? Let's just drop all the Hurd features and
implement the same interface as Linux, as exactly as we can make i
On Tue, 2007-04-10 at 11:46 +0200, Neal H. Walfield wrote:
> At Mon, 9 Apr 2007 20:02:32 -0700 (PDT),
> Roland McGrath <[EMAIL PROTECTED]> wrote:
> >
> > It is supposed to crash. Hopefully it does not hold locks while doing so,
> > and we should make sure that it doesn't. But anything that retu
Hello!
We're still being again and again annoyed by programs that use `PATH_MAX'
unconditionally.
I propose the following: we define it in glibc. But wait, we don't just
define it, we also try to help the programmer. It works roughly as
follows:
To `[glibc]/include/libc-symbols.h' we add:
#v
Hello!
On Tue, Apr 10, 2007 at 09:30:15AM -0700, Roland McGrath wrote:
> Sorry, I can't agree. glibc on Linux also sometimes changes so that things
> that previously got EFAULT start crashing instead.
I can clearly see the point you're trying to make. Quality of software,
including to not rely
At Tue, 10 Apr 2007 17:25:54 +0200,
<[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> On Mon, Apr 09, 2007 at 10:50:26PM +0200, Thomas Schwinge wrote:
>
> > The same happens when passing NULL file names to `open' and a lot (if
> > not all) of their friends.
>
> Yes, that was the Qt situation.
>
> > So, s
Hi,
On Mon, Apr 09, 2007 at 10:50:26PM +0200, Thomas Schwinge wrote:
> The same happens when passing NULL file names to `open' and a lot (if
> not all) of their friends.
Yes, that was the Qt situation.
> So, should instead `file_name_lookup' or `hurd_file_name_lookup' be
> made robust enough to
Sorry, I can't agree. glibc on Linux also sometimes changes so that things
that previously got EFAULT start crashing instead.
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-hurd
Hello!
Still while trying to get us an up-to-date git binary package I saw its
test suite hang, system got instable, tried to attach gdb to the affected
ext2fs instance, system crashed. Barry restored the system. This time I
first attached a ``noninvasive'' gdb to the ext2fs instance, re-ran the
At Mon, 9 Apr 2007 20:02:32 -0700 (PDT),
Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> It is supposed to crash. Hopefully it does not hold locks while doing so,
> and we should make sure that it doesn't. But anything that returns EFAULT
> on Linux has every right to crash with SIGSEGV or SIGBUS
