Re: PATH_MAX on the Hurd

My impression is that a good deal of code wants PATH_MAX because it wants to create an array of size PATH_MAX. Definitely true. That is by far the most common use of PATH_MAX in my experience.

Re: PATH_MAX on the Hurd

On 08/05/2011 04:25 PM, Eric Blake wrote: > What if we go with the array approach, but without risking > overallocation problems? Well again, it depends on what the test is for. My impression is that a good deal of code wants PATH_MAX because it wants to create an array of size PATH_MAX. If that'

Re: PATH_MAX on the Hurd

On 08/05/2011 05:19 PM, Paul Eggert wrote: On 08/05/2011 03:33 PM, Bruno Haible wrote: int a = PATH_MAX; Shouldn't this be: static int a[PATH_MAX]; Maybe. Or possibly: enum { a = PATH_MAX }; Are there cases when these three declarations don't all succeed and don't all fail? Oh yes. :-)

Re: PATH_MAX on the Hurd

On 08/05/2011 03:33 PM, Bruno Haible wrote: >>> int a = PATH_MAX; >> > >> > Shouldn't this be: >> > >> > static int a[PATH_MAX]; > Maybe. Or possibly: > enum { a = PATH_MAX }; > > Are there cases when these three declarations don't all succeed and don't > all fail? Oh yes. :-) "int a = PATH_MA

Re: PATH_MAX on the Hurd

Eric Blake wrote: > > int a = PATH_MAX; > > Shouldn't this be: > > static int a[PATH_MAX]; Maybe. Or possibly: enum { a = PATH_MAX }; Are there cases when these three declarations don't all succeed and don't all fail? I'm not so familiar with the various classes of constant expressions. Paul

Re: PATH_MAX on the Hurd

On 08/04/2011 07:14 PM, Bruno Haible wrote: /* Check that PATH_MAX is a constant if it is defined. */ #ifdef PATH_MAX int a = PATH_MAX; Shouldn't this be: static int a[PATH_MAX]; so that we really are testing that it is a constant? And do we also want to enforce that it is usable as a pre

Re: PATH_MAX on the Hurd

> pathmax: Leave PATH_MAX undefined on the Hurd, and a constant otherwise. And to make it clear what semantics pathmax.h exactly provides, I'm adding a unit test: 2011-08-04 Bruno Haible Tests for module 'pathmax'. * modules/pathmax-tests: New file. * tests/test

Re: PATH_MAX on the Hurd

Paul Eggert wrote: > One nit: the pathmax.h comment suggests a fallback of 8192, > but the code uses 1024; I suggest making them consistent. Yup. I think this patch makes it more consistent: 2011-08-04 Bruno Haible canonicalize-lgpl: Support larger filenames on the Hurd. * li

Re: PATH_MAX on the Hurd

Simon Josefsson wrote: > After applying it, getcwd builds and passes > selftests [1], so please push it. Great! Thanks for the testing. Paul Eggert wrote: > the pathmax.h comment suggests a fallback of 8192, > but the code uses 1024; I suggest making them consistent. Good point. Actually the bes

Re: PATH_MAX on the Hurd

Bruno Haible writes: > Yes, this was precisely the topic of the two threads that started at > > and . > > The root of the problem is that we have two ways to de

Re: PATH_MAX on the Hurd

I like Bruno's patch better than what I proposed. One nit: the pathmax.h comment suggests a fallback of 8192, but the code uses 1024; I suggest making them consistent. If the common idiom is a local variable of size PATH_MAX, perhaps the default should be 4000 or so?

Re: PATH_MAX on the Hurd

Hi Simon, > I'm trying to get gnulib to work on the Hurd, and ran into this in > test-getcwd.c: > > test-getcwd.c: In function 'test_long_name': > test-getcwd.c:119:11: error: missing binary operator before token "(" > > The code is: > > 29#include "pathmax.h" > ... >108