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 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
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_list
-#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 with no
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
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:
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 relationship
