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
web.
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:
> >
> >
> > 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:
netsurf/utils/filepath.c
These functions are being called from:
netsurf/frontends/gtk/fetch.c
netsurf/frontends/gtk/gui.c
netsurf/frontends/framebuffer/fetch.c
netsurf/frontends/framebuffer/font_freetype.c
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
Regards,
João