RE: [PATCH] Build on Debian GNU/Hurd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thurs Sept 21 at 18:54, Linus Torvalds wrote:
> On Thu, 21 Sep 2006, Ramsay Jones wrote:
> >
> > IMHO, setting the value in the Makefile, for systems that don't define
> > PATH_MAX, is a much better solution. In fact, that is what I thought was
> > already being done.
>
> Well, considering that we _can_ test defines, why not just do it
> automatically.
>
> In other words, instead of this patch:
>
> > >  -
> > >  -#ifndef PATH_MAX
> > >  -# define PATH_MAX 4096
> > >  -#endif
> > >  +#include <limits.h>
>
> Just make the code read
>
> 	#include <limits.h>
>
> 	/*
> 	 * Insane systems don't have a fixed PATH_MAX, it's POSIX
> 	 * compliant but not worth worrying about, so if we didn't
> 	 * get PATH_MAX from <limits.h>, just make up our own
> 	 */
> 	#ifndef PATH_MAX
> 	# define PATH_MAX 4096
> 	#endif
>
> and after that we can just ignore the issue forever more.

Yes, that would certainly be a solution. (Of course, setting the value in
the Makefile would still be a better solution ;-)
However, ...

>
> The thing is, it's not like we even really _care_ what PATH_MAX is all
> that deeply. We just want to get some random value that is reasonable.
>
> 		Linus
>

... given the above, a better solution is: don't use PATH_MAX.
Simply #define a new symbol in a suitable git header file and globally
replace uses of PATH_MAX with the new symbol. Job done.

All the best,

Ramsay

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]