On Wednesday 14 March 2007 02:15, Linus Torvalds wrote:
> Sure. I'm just saying that some people may use OPEN_MAX the way I know
> people use PATH_MAX - whether it's what you're supposed to or not.
glibc removed OPEN_MAX from its header files several years ago. If you
want to find a piece of code
Hi,
On 14 Mar 2007, at 01:15, Linus Torvalds wrote:
On Tue, 13 Mar 2007, Roland McGrath wrote:
Ok, fine. But PATH_MAX is a real constant that has some meaning
in the
kernel. It's perfectly correct to use PATH_MAX as a constant on a
system
like Linux that defines it and means what it says.
On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> Ok, fine. But PATH_MAX is a real constant that has some meaning in the
> kernel. It's perfectly correct to use PATH_MAX as a constant on a system
> like Linux that defines it and means what it says. Conversely, OPEN_MAX
> has no useful relationsh
> I'd actually prefer this as part of the "remove OPEN_MAX" patch.
Ok. (But now you're going to argue with me about "remove OPEN_MAX",
and you haven't said you have any problem with changing SCM_MAX_FD,
so why make it wait?)
> That said, it actually worries me that you should call "_SC_OPEN_MAX"
On Tue, 13 Mar 2007, Roland McGrath wrote:
>
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. SCM_MAX_FD is just an arbitrary
> constant and it should be clear that its value is chosen in net/scm.h
> and not actually derived from
> > -#define SCM_MAX_FD (OPEN_MAX-1)
> > +#define SCM_MAX_FD (NR_OPEN-1)
>
> This is a bad idea. [...]
Ok. My only agenda is to get rid of OPEN_MAX.
I then propose the following instead.
Thanks,
Roland
---
[PATCH] avoid OPEN_MAX in SCM_MAX_FD
The OPEN_MAX constant is an arbitrary number wit
On Tue, Mar 13, 2007 at 01:39:12AM -0700, Roland McGrath wrote:
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. This patch changes SCM_MAX_FD to
> use NR_OPEN instead of OPEN_MAX. This increases the size of the struct
> scm_fp_lis
