This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] compile: rm -rf -> ftw()+rmdir()+unlink() [Re: [patch] compile: Fix MinGW build]

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
	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
and _FILE_OFFSET_BITS=64 happens on 32-bit hosts and --enable-64-bit-bfd.

Contrary to it gnulib fts documentation
	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).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]