Re: [RFC PATCH 0/6] Enable building Gnu Global package on Hurd

[Shigio YAMAGUCHI]

Hi,

> On digging futher[2][3], I came to the conclusion that instead of

> defining PATH_MAX to a value, the way to fix it would be to change how

> paths are handled. Although the changes are not difficult, one needs

> to be careful to free the buffers when they are no longer

> needed. Thought a bit tedious, the arguments against using PATH_MAX

> (but also other similar macros) make sense.

I agree with you.

> Before applying the patch to the global package, I was hoping to get

> some feedback and a view on whether they could be merged

> upstream. There is nothing debian specific in the patches.

I have committed the patches to the repository.

Thank you for the better code.

> shows ~150+ locations where MAXPATHLEN is used. Is there interest to

> address this? Would more such patches updating the code be useful?  Or

> is there a better way to go about this?

Such patches and guidelines are welcome.

Thank you very much.

Regards,

Shigio

2017-01-24 7:43 GMT+09:00 Punit Agrawal <address@hidden>:

Hi,

Gnu Global package in Debian fails to build from source on Hurd[0] as
the build errors out when PATH_MAX is not defined. Here's the snippet
from libutil/find.c that triggers the failure -

#ifndef PATH_MAX
#error Since this platform does not have PATH_MAX, you should define it using an appropriate value for the platform.
/* #define PATH_MAX     1024 */
#endif

On digging futher[2][3], I came to the conclusion that instead of
defining PATH_MAX to a value, the way to fix it would be to change how
paths are handled. Although the changes are not difficult, one needs
to be careful to free the buffers when they are no longer
needed. Thought a bit tedious, the arguments against using PATH_MAX
(but also other similar macros) make sense.

In this series the dependency on PATH_MAX is dropped so that the build
succeeds on Hurd.

Patches 1 & 2 are a couple of minor cleanups. Patch 3-5 update
instances where the macro is used. Patch 6 drops the offending snippet
above.

Before applying the patch to the global package, I was hoping to get
some feedback and a view on whether they could be merged
upstream. There is nothing debian specific in the patches.

I'd also like to take this opportunity to raise the larger question of
how to address similar issues elsewhere in the codebase. A quick grep
shows ~150+ locations where MAXPATHLEN is used. Is there interest to
address this? Would more such patches updating the code be useful?  Or
is there a better way to go about this?

Feedback and opinions welcome.

Thanks,
Punit

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848302
[1] http://cvs.savannah.gnu.org/viewvc/global/global/libutil/find.c?view=markup#l82
[2] https://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html
[3] https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_MAX_PATH_tt_MAXPATHL

Punit Agrawal (6):
  libutil: Drop extraneous function declarations
  libutil: Staticize locally used functions
  libutil: Remove usage of PATH_MAX from getrealpath
  libutil: Remove usage of PATH_MAX from has_symlinkloop
  libutil: Convert rootdir to a dynamically allocated array
  libutil: Drop the requirement for PATH_MAX macro

 libutil/find.c | 219 ++++++++++++++++++++++++++++++---------------------------
 1 file changed, 114 insertions(+), 105 deletions(-)

--
2.11.0


_______________________________________________
Bug-global mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-global

--

Shigio YAMAGUCHI <address@hidden>

PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3