From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752682AbXCNAzS (ORCPT ); Tue, 13 Mar 2007 20:55:18 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752679AbXCNAzR (ORCPT ); Tue, 13 Mar 2007 20:55:17 -0400 Received: from mx1.redhat.com ([66.187.233.31]:56815 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674AbXCNAzQ (ORCPT ); Tue, 13 Mar 2007 20:55:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Linus Torvalds X-Fcc: ~/Mail/linus Cc: Benjamin LaHaise , Andrew Morton , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 1/2] avoid OPEN_MAX in SCM_MAX_FD In-Reply-To: Linus Torvalds's message of Tuesday, 13 March 2007 14:28:00 -0700 X-Fcc: ~/Mail/linus X-Antipastobozoticataclysm: When George Bush projectile vomits antipasto on the Japanese. Message-Id: <20070314005508.DDC121801C5@magilla.sf.frob.com> Date: Tue, 13 Mar 2007 17:55:08 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > 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". [...] > For example, I know perfectly well that I should use _SC_PATH_MAX, but a > *lot* of code simply doesn't care. In git, I used PATH_MAX, and the reason [...] 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 with anything the kernel is doing at all. > So, what's the likelihood that this will break some old programs? I > realize that modern distributions don't put the kernel headers in their > user-visible includes any more, but the breakage is most likely exactly > for old programs and older distributions. Well, I don't know for sure. It doesn't seem all that likely to me (not like PATH_MAX), as there has been getdtablesize() since before there was OPEN_MAX by that name (not to mention before there was Linux). If things use OPEN_MAX as a constant for arrays, they're already broken unless they call setrlimit to constrain themselves. Getting things fixed has to start somewhere. Thanks, Roland