This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Add C11 threads.h support.
- From: Rich Felker <dalias at libc dot org>
- To: Juan Manuel Torres Palma <j dot m dot torrespalma at gmail dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Sat, 27 Jun 2015 14:51:11 -0400
- Subject: Re: [RFC] Add C11 threads.h support.
- Authentication-results: sourceware.org; auth=none
- References: <CAD82F-pXPRnsxLtT2pTADWkjsV=m6xA7cDuMX6J_bXW+c=HsVA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1506262111460 dot 28580 at digraph dot polyomino dot org dot uk> <CAD82F-qU-m19vK43WROzez29vUVREgRS_ohA45tJWwnXUsdkZg at mail dot gmail dot com>
On Sat, Jun 27, 2015 at 05:04:26PM +0200, Juan Manuel Torres Palma wrote:
> > You need to call the implementation-namespace names such as
> > __pthread_once. It's not enough that they exist if you then use the other
> > names for those functions; you must avoid any strong references (defined
> > or undefined) to names outside the C11 and implementation namespaces (and
> > any uses of weak undefined symbols outside those namespaces that might get
> > executed for conforming code).
>
> I don't get this point either. I thought this code will be executing
> inside the library, where __pthread_* symbols are exactly the same
> than pthread_* symbols. So, if the user redefines pthread_* symbols
> (He's a llowed to do that), won't affect symbols inside library. Am I
> wrong?
Yes, you're wrong about this. pthread_* are not reserved in a plain C
program that does not use POSIX; an application can define them (or
any other POSIX symbols that aren't in plain C) for any purpose it
wants.
There is no such thing as "inside the library" except possibly as a
linking optimization for shared libraries. With an archive (static)
library, object files from the library have no special status distinct
from object files provided by the program or third-party libraries.
Rich