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.
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
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
At Tue, 10 Apr 2007 22:10:01 -0700,
Thomas Bushnell BSG [EMAIL PROTECTED] wrote:
[1 text/plain (quoted-printable)]
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
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
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 text/plain (quoted-printable)]
On Tue, 2007-04-10 at 21:44 +0200, Thomas Schwinge wrote:
Hello!
We're still being again and again
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
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
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
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, should instead
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:
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 returns
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 it.
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
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 Address 0x4002 out of bounds, flags=0,
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
16 matches
Mail list logo
