[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Netsurf build failure: 'PATH_MAX' undeclared

Unsubscribe me from the list 

On Mon, Apr 26, 2021, at 12:31 PM, João Pedro Malhado wrote:
Hello everyone,

Replacing all PATH_MAX by _POSIX_PATH_MAX on all files concerned in the build
rules does result in a successful build and a browser that loads pages from the

If we can decide on what is a reasonable technical solution in this case, we
would then have another ported package users can use ;)
another solution would be better, then we would be done with this package.

On Mon, Apr 26, 2021 at 01:36:54PM +0200, Samuel Thibault wrote:
> João Pedro Malhado, le lun. 26 avril 2021 12:51:34 +0200, a ecrit:
> > It does seem this is a documented issue:
> > 
> > https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL
> > 
> > What would be a reasonable approach here, change to use _POSIX_PATH_MAX?

> See what the page says:

> Note: constants such as _POSIX_PATH_MAX are only the minimum required
> value for a potential corresponding PATH_MAX macro. They are not a
> replacement for PATH_MAX, just the minimum value that one can assume.

> What would be best suited completely depends on what the buf purpose is
> at all, whether the size is actually known and just needs to be
> computed, or else use dynamic allocation. I'm here basically just
> rephrasing the page...

Yes, I did notice that. And I understand that the way I posed the question did
not have a well defined answer without knowledge of the specific context.

My knowledge of C goes as far as trying to change the size of the string. If
dynamic allocation would be a better solution, I would need help doing that: how
to declare the variable, how to allocate, what to allocated to, how to deallocate.

There are 5 relevant files where this PATH_MAX shows up. In all cases the string
corresponds to a file path and either the function filepath_sfind() or
filepath_defsfind() is being called (gtk_fetch_filetype_init() is also called
but does not seem to have PATH_MAX hard-coded).

The two filepath_* functions are defined in:


These functions are being called from:





What would be a good solution in this case?
How big/small is _POSIX_PATH_MAX, and what problems may that create (also for
the linux build)?

Perhaps interestingly ATARI also seems to have problems with PATH_MAX, as per
line 36 in netsurf/utils/filepath.c:

#include "utils/dirent.h" /** \todo why is this necessary for atari to get
PATH_MAX and is there a better way */

Some sort of hack seems to have been found there. I don't know if it would apply
to the hurd, but it does not seem very elegant. The atari code path seems to
have loads PATH_MAX


Reply to: