mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: C++ ABI TODO list
Date: Sat, 20 Jul 2013 01:26:14 -0400	[thread overview]
Message-ID: <20130720052614.GA17733@brightrain.aerifal.cx> (raw)

Here are the changes I'm aware of that would be needed to bring musl's
C++ ABI in line with glibc/LSB, enabling C++ library reuse with musl:

Making FILE match is easy: __FILE_s -> _IO_FILE

glibc defines mbstate_t as a structure with no tag. As far as I can
tell (simple C++ test program), the name mangling then comes fully
from the typedef name, so I think we might be okay on mbstate_t
already.

glibc's fpos_t is defined as _G_fpos_t or _G_fpos64_t depending on
_FILE_OFFSET_BITS, so the type name for C++ name mangling should be
_G_fpos64_t on 32-bit machines, but I'm uncertain which it should be
on 64-bit ones. Does anybody use these horrible fpos functions anyway?

Fixing jmp_buf and sigjmp_buf requires making them both the same type,
struct __jmp_buf_tag. Instead of storing a whole HURD sigset, the
unified jmp_buf should only store _NSIG. The full type with the extra
slots for sigsets (not just space for machine regs) should be defined
in alltypes.h (since it needs to be aware of the number of signals the
arch has, and _NSIG is not visible in setjmp.h).

In order to keep the error detection properties of musl's pthread_t,
it should be redefined as:

#ifdef __cplusplus
TYPEDEF unsigned long pthread_t;
#else
TYPEDEF struct __pthread pthread_t;
#endif

(We could further add similar conditional definition for timer_t.)

Most of the above were taken from the old "Remaining ABI issues"
thread (January 2013) and some quick experimentation with glibc. Note
that the old issues (in that thread) about timer_t having pointer type
are gone; POSIX-2008-TC1 adopted my requested change to remove the
requirement that timer_t have arithmetic type.

I'm hoping the above list is all...

Rich


             reply	other threads:[~2013-07-20  5:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-20  5:26 Rich Felker [this message]
2013-07-22 15:45 ` Rich Felker
2013-07-22 18:20   ` Rich Felker

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=20130720052614.GA17733@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

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 NNTP newsgroup(s).