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]
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
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
