On Wed, Jan 25, 2017 at 6:30 AM, Shigio YAMAGUCHI <shi...@gnu.org> wrote: > 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.
Thanks for merging the patches. I'll upload a new package with them until the next upstream release. > >> 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. That's good to know. Next time I'll pick such a task in global I'll feel less hesitant. :) Thanks, Punit > Thank you very much. > > Regards, > Shigio > > > 2017-01-24 7:43 GMT+09:00 Punit Agrawal <punitagra...@gmail.com>: >> >> 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 >> Bug-global@gnu.org >> https://lists.gnu.org/mailman/listinfo/bug-global > > > > > -- > Shigio YAMAGUCHI <shi...@gnu.org> > PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3 _______________________________________________ Bug-global mailing list Bug-global@gnu.org https://lists.gnu.org/mailman/listinfo/bug-global