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

[Punit Agrawal]

On Wed, Jan 25, 2017 at 6:30 AM, Shigio YAMAGUCHI  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 :
>>
>> 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 
> 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

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 :

> 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 
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