From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6940 invoked by alias); 19 Dec 2014 19:25:17 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 6931 invoked by uid 89); 19 Dec 2014 19:25:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 19 Dec 2014 19:25:15 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sBJJP2oF020841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Dec 2014 14:25:02 -0500 Received: from host2.jankratochvil.net (ovpn-116-142.ams2.redhat.com [10.36.116.142]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id sBJJOvHC029231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Dec 2014 14:25:00 -0500 Date: Fri, 19 Dec 2014 19:25:00 -0000 From: Jan Kratochvil To: Pedro Alves Cc: Kai Tietz , Eli Zaretskii , sellcey@imgtec.com, brobecker@adacore.com, yao@codesourcery.com, gdb-patches@sourceware.org Subject: Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build] Message-ID: <20141219192457.GA28791@host2.jankratochvil.net> References: <20141217210144.GA26674@host2.jankratochvil.net> <83wq5oub28.fsf@gnu.org> <20141218173103.GA18871@host2.jankratochvil.net> <83sigcua9l.fsf@gnu.org> <526566540.670835.1418933688966.JavaMail.zimbra@redhat.com> <5493678F.4050906@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5493678F.4050906@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00582.txt.bz2 On Fri, 19 Dec 2014 00:47:27 +0100, Pedro Alves wrote: > For our purposes, both APIs are just as good (*). It's just > that ftw has System V roots, while fts has BSD roots. > > In practice, programs that use fts instead are just, if not > more portable. > > But, as I mentioned, gnulib provides an fts replacement > for systems that don't have it. So if we use fts instead, we're > good to go everywhere. Linux fts man page http://man7.org/linux/man-pages/man3/fts.3.html says BUGS All of the APIs described in this man page are not safe when compiling a program using the LFS APIs (e.g., when compiling with -D_FILE_OFFSET_BITS=64). and _FILE_OFFSET_BITS=64 happens on 32-bit hosts and --enable-64-bit-bfd. Contrary to it gnulib fts documentation https://www.gnu.org/software/gnulib/manual/html_node/fts_005fread.html says On platforms where off_t is a 32-bit type, this function may not correctly report the size of files or block devices larger than 2 GB and may not work correctly on huge directories larger than 2 GB. Also, on platforms where ino_t is a 32-bit type, this function may report inode numbers incorrectly. The fix is to use the AC_SYS_LARGEFILE macro (only on Mac OS X systems). This would suggest as if GDB should be compatible with 32-bit hosts and --enable-64-bit-bfd GDB should use gnulib fts even on Linux; but I guess the gnulib fts replacement would not be active on Linux. The temporary files being deleted are never larger than 2GB nor their size is read. So I hope nobody is going address these issues (I would add 32-bit hosts are not relevant anymore anyway). Jan