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 <[email protected]>: > 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/bug-global > -- Shigio YAMAGUCHI <[email protected]> PGP fingerprint: D1CB 0B89 B346 4AB6 5663 C4B6 3CA5 BBB3 57BE DDA3
_______________________________________________ Bug-global mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-global
