From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 566 invoked by alias); 18 Oct 2002 18:59:07 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 537 invoked from network); 18 Oct 2002 18:59:05 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.163.212.31) by sources.redhat.com with SMTP; 18 Oct 2002 18:59:05 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id DC689357E; Fri, 18 Oct 2002 11:59:04 -0700 (PDT) Received: (from roland@localhost) by magilla.sf.frob.com (8.11.6/8.11.6) id g9IIx4500417; Fri, 18 Oct 2002 11:59:04 -0700 Date: Fri, 18 Oct 2002 12:04:00 -0000 Message-Id: <200210181859.g9IIx4500417@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Jakub Jelinek Cc: Ulrich Drepper , Glibc hackers Subject: Re: [PATCH] Fix {,f}pathconf In-Reply-To: Jakub Jelinek's message of Friday, 18 October 2002 16:59:50 +0200 <20021018165950.T3451@sunsite.ms.mff.cuni.cz> Emacs: the definitive fritterware. X-SW-Source: 2002-10/txt/msg00069.txt.bz2 > Recent pathconf changes broke alpha build (both linux/pathconf.c and > alpha/linux/pathconf.c are redefining __pathconf). Oops, braino on my part. > But looking at it I found that alpha/*pathconf.c is bogus, not just alpha > but all linux platforms support files >= 2GB on some filesystems. Ok, but this changes the answers seen now and I don't know what users expect. I like your changes to make the code generic, but the exact values you use are wrong. I think users will expect to see 32 or 64 and not anything else. FILESIZEBITS is not specified as the exact log2 of the maximum file size, but rather as the minimum number of bits needed to represent *as a signed integer* the maximum file size. So, for 2GB files it needs to be 32, not 31--moreover, POSIX.1 specifies that 32 is the minimum value an implementation can define. It would meet the spec to return 42 when the max size if 2^41-1, but I think it's a better plan to return 64, and in the general case to return the bitcount of the off_t equivalent type appropriate for the filesystem rather than its internal storage format limit. > Looking at the kernel, it is really a mess to find out what the maximum > filesizes are, but I've at least tried. Ideally kernel would implement > itself *pathconf (and even then s_maxbytes would have to be cleaned up). We are all agreed here, but the kernel people never helped in the past.