From patchwork Mon Mar 17 17:44:52 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?T25kxZllaiBCw61sa2E=?= X-Patchwork-Id: 331365 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 22A132C0099 for ; Tue, 18 Mar 2014 20:30:00 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; q=dns; s=default; b=KECgD4zG8+tZPQU5jYcv/svD0UaZ3L PmjSjjSi0ShFuNlTizeswwgEqchO8+BEQleAd8qrI0cSgpluC611Mkru8ma8xkA3 OE1/paUBFZGb+VcjiXNIDXxO6ld0EY+3q0g1oFkkYEvAPbhAIYTgmLjHlP4QNUYc FA/OABHtlhXus= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-transfer-encoding :in-reply-to; s=default; bh=7Qfs9mt4TVd1/c+E4QZVsqP1FUs=; b=cQPj qN9l6h/HPPgmfrwIgIxgug3eauGMJpSa8qbjbXNExoKWN0NcJkGY7KX574Bfri3P wSYDWa6Q1Ck3YEZgH+TFiOW+RwS3Rm85gRWA513knry1qAt96n8SZR6OvSw9agoa qp7DXNIpIUnvGKxv5p3XrvgzO4ihJ0Lqt8pUaoA= Received: (qmail 9656 invoked by alias); 18 Mar 2014 09:29:54 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 9645 invoked by uid 89); 18 Mar 2014 09:29:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, SPF_NEUTRAL autolearn=no version=3.3.2 X-HELO: popelka.ms.mff.cuni.cz Date: Mon, 17 Mar 2014 18:44:52 +0100 From: =?utf-8?B?T25kxZllaiBCw61sa2E=?= To: Mike Frysinger Cc: libc-alpha@sourceware.org, Paul Eggert , Denis Obrezkov Subject: [PATCH] Warn about using _ino_t without -D_FILE_OFFSET_BITS=64. Message-ID: <20140317174452.GA10644@domone> References: <1393521776-1102-1-git-send-email-reprofy@etersoft.ru> <530F79C1.2040508@cs.ucla.edu> <20140305091331.GA6031@domone.podge> <5239512.EEmGNsN1rx@vapier> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5239512.EEmGNsN1rx@vapier> User-Agent: Mutt/1.5.20 (2009-06-14) On Tue, Mar 11, 2014 at 06:51:55AM -0400, Mike Frysinger wrote: > On Wed 05 Mar 2014 10:13:31 Ondřej Bílka wrote: > > On Thu, Feb 27, 2014 at 09:45:37AM -0800, Paul Eggert wrote: > > > Squashing an inode that way has a small chance of introducing what > > > could be a serious bug. If glibc is going to squash them, it should > > > do so reliably, by maintaining a table of all the inodes it's ever > > > seen and making sure there are no collisions. > > > > > > Why bother to squash them at all, though? Programs that care about > > > files should be compiled with _FILE_OFFSET_BITS defined to 64. If > > > we're worried about programs that don't define _FILE_OFFSET_BITS, we > > > could change glibc to default to _FILE_OFFSET_BITS=64; that's a > > > better long-term solution anyway. > > > > Changing default would be better. I dig while how to do it and can not > > find a nonugly solution. How should we do this? > > isn't it simply: > > --- a/include/features.h > +++ b/include/features.h > @@ -303,7 +303,7 @@ > # define __USE_LARGEFILE64 1 > #endif > > -#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 > +#if !defined _FILE_OFFSET_BITS || _FILE_OFFSET_BITS == 64 > # define __USE_FILE_OFFSET64 1 > #endif > > > the glibc source files themselves seem to expect default of > _FILE_OFFSET_BITS=32 though, so we might have to add that to default CPPFLAGS > when building. > > i kind of feel like deploying this on Gentoo systems to see what breaks ;). > -mike Yes, it is. Could we in this release at least add this warning? I tried to restrict warning only when _ino_t is used but warning attribute does not apply to types and using __attribute__ ((deprecated)) would confuse users. * dirent/dirent.h [defined __USE_XOPEN && defined __ino_t_defined && ! defined __USE_FILE_OFFSET64]: Add warning. diff --git a/dirent/dirent.h b/dirent/dirent.h index f6db6c6..35c0a93 100644 --- a/dirent/dirent.h +++ b/dirent/dirent.h @@ -31,6 +31,7 @@ __BEGIN_DECLS #ifdef __USE_XOPEN # ifndef __ino_t_defined # ifndef __USE_FILE_OFFSET64 +# warning Please use -D_FILE_OFFSET_BITS=64 to support long files. typedef __ino_t ino_t; # else typedef __ino64_t ino_t;