public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs
@ 2013-07-21 19:21 bugdal at aerifal dot cx
2013-07-21 20:34 ` [Bug libc/15767] " schwab@linux-m68k.org
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: bugdal at aerifal dot cx @ 2013-07-21 19:21 UTC (permalink / raw)
To: glibc-bugs
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/15767] C++ ABI inconsistency for fpos_t on 64-bit archs
2013-07-21 19:21 [Bug libc/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs bugdal at aerifal dot cx
@ 2013-07-21 20:34 ` schwab@linux-m68k.org
2013-07-21 22:09 ` joseph at codesourcery dot com
2014-06-13 13:20 ` fweimer at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: schwab@linux-m68k.org @ 2013-07-21 20:34 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15767
Andreas Schwab <schwab@linux-m68k.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |DUPLICATE
--- Comment #1 from Andreas Schwab <schwab@linux-m68k.org> ---
.
*** This bug has been marked as a duplicate of bug 15766 ***
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/15767] C++ ABI inconsistency for fpos_t on 64-bit archs
2013-07-21 19:21 [Bug libc/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs bugdal at aerifal dot cx
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
2 siblings, 0 replies; 4+ messages in thread
From: joseph at codesourcery dot com @ 2013-07-21 22:09 UTC (permalink / raw)
To: glibc-bugs
http://sourceware.org/bugzilla/show_bug.cgi?id=15767
--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Sun, 21 Jul 2013, bugdal at aerifal dot cx wrote:
> 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.
In general _FILE_OFFSET_BITS can change types even on 64-bit
architectures. In particular, on MIPS n64, struct stat and struct stat64
are different (I don't know whether this was a historical accident, or an
attempt at binary compatibility with IRIX), with the consequence that n64
does not use sysdeps/unix/sysv/linux/wordsize-64/, and meaning that
_FILE_OFFSET_BITS=64 changes the struct stat layout to match struct stat64
and maps all functions using struct stat to the versions that use struct
stat64 - and for ABI compatibility, it can't stop doing so.
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug libc/15767] C++ ABI inconsistency for fpos_t on 64-bit archs
2013-07-21 19:21 [Bug libc/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs bugdal at aerifal dot cx
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
2 siblings, 0 replies; 4+ messages in thread
From: fweimer at redhat dot com @ 2014-06-13 13:20 UTC (permalink / raw)
To: glibc-bugs
https://sourceware.org/bugzilla/show_bug.cgi?id=15767
Florian Weimer <fweimer at redhat dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Flags| |security-
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-06-13 13:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-21 19:21 [Bug libc/15767] New: C++ ABI inconsistency for fpos_t on 64-bit archs bugdal at aerifal dot cx
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
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).