[patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]
Jan Kratochvil
jan.kratochvil@redhat.com
Fri Dec 19 19:25:00 GMT 2014
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
More information about the Gdb-patches
mailing list