Hello!
On Thu, Apr 12, 2007 at 01:49:55PM -0700, Roland McGrath wrote:
> I think tb has covered the essence here already. tschwinge, your comments
> here are really not apropos, and frankly they seem gratuitously hostile to
> the basic principles that have always driven Hurd development.
I apolo
I appreciate the intent of your suggestion, but I don't think it can
actually meet its goals.
I don't think that defining PATH_MAX invalidly will actually be a net gain
at all. If defined, PATH_MAX must be a constant. If you have a plan and
you cannot compile:
static char name[PATH_MAX]
I think tb has covered the essence here already. tschwinge, your comments
here are really not apropos, and frankly they seem gratuitously hostile to
the basic principles that have always driven Hurd development. I really do
appreciate your frustrations. We've felt them for a very long time too.
At Wed, 11 Apr 2007 10:56:18 +0200,
Neal H. Walfield wrote:
>
> At Tue, 10 Apr 2007 22:10:01 -0700,
> Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
> >
> > [1 ]
> > On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
> > > Hello!
> > >
> > > We're still being again and again annoyed by p
Hi,
On Wed, Apr 11, 2007 at 10:56:18AM +0200, Neal H. Walfield wrote:
> Legacy compatibility has always ruled the day.
Standards compatibility, not bug compatibility...
-antrik-
___
Bug-hurd mailing list
Bug-hurd@gnu.org
http://lists.gnu.org/mailman
At Tue, 10 Apr 2007 22:10:01 -0700,
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote:
>
> [1 ]
> 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?
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
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
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 there too, and on
the Hurd we explicitly intend that bad addresses cause crashes and not
err
Hello!
On Mon, Apr 09, 2007 at 08:43:25PM +0200, I wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0x0105fc56 in __hurd_file_name_lookup (use_init_port=0x101aba8,
> get_dtable_port=0x4002, lookup=0,
> file_name=0x4002 , flags=0,
> mode=1073741826, result=0x4002)
Hello!
While bringing the git rcs's binary package in an up-to-date state for
us, I saw the following: I saw it segfault.
#v+
Starting program: /devel3/tschwinge/tmp/git/git-core-1.5.1/git add .
Program received signal SIGSEGV, Segmentation fault.
0x0105fc56 in __hurd_file_name_lookup (use_init_
17 matches
Mail list logo