public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/15838] New: fts.h interfaces are presently non-usable except on 64-bit systems
Date: Wed, 14 Aug 2013 19:32:00 -0000	[thread overview]
Message-ID: <bug-15838-131@http.sourceware.org/bugzilla/> (raw)

http://sourceware.org/bugzilla/show_bug.cgi?id=15838

            Bug ID: 15838
           Summary: fts.h interfaces are presently non-usable except on
                    64-bit systems
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

fts.h contains the following:

/* The fts interface is incompatible with the LFS interface which
   transparently uses the 64-bit file access functions.  */
#ifdef __USE_FILE_OFFSET64
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
#endif

Thus, the whole fts.h API is useless except on 64-bit machines. Assuming a
32-bit system, if 64-bit off_t is used, fts.h explicitly generates an error. If
32-bit off_t is used, fts will fail at runtime because stat fails with
EOVERFLOW when the inode number or file size does not fit in 32 bits, making
any program using the fts interfaces unreliable.

I would prefer just deprecating this whole API, removing the header and using
symbol versioning to prevent new apps from linking to it. There is a perfectly
good version, without the 32-bit limitations, in gnulib which apps can use if
they need it, and there are various BSD versions that also work fine. The
breakage in the glibc version is purely from keeping ABI compatibility with the
old 32-bit off_t interfaces.

Alternatively, FTS64, fts_open64, etc. could be added...

-- 
You are receiving this mail because:
You are on the CC list for the bug.


             reply	other threads:[~2013-08-14 19:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-14 19:32 bugdal at aerifal dot cx [this message]
2014-02-26 17:35 ` [Bug libc/15838] " rjones at redhat dot com
2014-06-13 13:12 ` fweimer at redhat dot com
2015-08-24  9:46 ` jsm28 at gcc dot gnu.org
2024-02-06 19:15 ` gabravier at gmail dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-15838-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).