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/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs Date: Sun, 21 Jul 2013 19:21:00 -0000 [thread overview] Message-ID: <bug-15767-131@http.sourceware.org/bugzilla/> (raw) http://sourceware.org/bugzilla/show_bug.cgi?id=15767 Bug ID: 15767 Summary: C++ ABI inconsistency for fpos_t on 64-bit archs 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 On 64-bit archs, -D_FILE_OFFSET_BITS=64 should not affect the C++ ABI (name mangling). Regardless of whether there's an official policy to this effect, it makes sense, since some applications will always compile with -D_FILE_OFFSET_BITS=64 and others will attempt to detect whether they need it before adding it. For most types that change definition according to _FILE_OFFSET_BITS, there is an underlying type name independent of the typedef name, and no issue arises. However, fpos_t is defined to a structure with no tag, and thus the original typedef name of either _G_fpos_t or _G_fpos64_t gets used in name mangling. Thus if a C++ library uses fpos_t as part of its public interface, and the library and application are compiled with different values of _FILE_OFFSET_BITS, the ABI will gratuitously mismatch. On 32-bit archs it should be expected to mismatch, and the library would have a policy that you have to build with 64-bit off_t. But on 64-bit archs, it should not matter whether _FILE_OFFSET_BITS was defined. This issue would be even more of a problem if multiple libraries disagreed on whether it was supposed to be set, and an application needed to use both libraries. With that said, I'm not sure why features.h doesn't make _FILE_OFFSET_BITS a complete no-op on 64-bit archs. That would make the issue go away entirely. -- You are receiving this mail because: You are on the CC list for the bug.
next reply other threads:[~2013-07-21 19:21 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-07-21 19:21 bugdal at aerifal dot cx [this message] 2013-07-21 20:34 ` [Bug libc/15767] " schwab@linux-m68k.org 2013-07-21 22:09 ` joseph at codesourcery dot com 2014-06-13 13:20 ` fweimer at redhat 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-15767-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: linkBe 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).