This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/10110] Separate __STDC_* predefines from features.h
- From: "jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 8 Jan 2011 17:05:28 +0000
- Subject: [Bug libc/10110] Separate __STDC_* predefines from features.h
- Auto-submitted: auto-generated
- References: <bug-10110-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=10110
--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2010-06-04 14:41:34 UTC ---
Subject: Re: Separate __STDC_* predefines from features.h
On Tue, 1 Jun 2010, pasky at suse dot cz wrote:
> So this should be now marked as SUSPENDED, waiting for the gcc changes, right?
No, the GCC changes are waiting on glibc maintainer feedback - feedback on
whether, given what I said, a libc change using a separate header only for
__STDC_ISO_10646__ would be acceptable, or whether it will be required for
GCC to extract the __STDC_ISO_10646__ value using fixincludes. The basic
GCC mechanism is needed in any case, but glibc maintainer feedback is
awaited to determine what the next pair of patches should look like.
--- Comment #6 from Joseph Myers <jsm28 at gcc dot gnu.org> 2011-01-08 17:05:10 UTC ---
Similar use cases for the glibc change and compiler feature also apply for some
optional C1X predefines (these are quite like the use case for DFP
implementation).
* Supposing glibc does not initially when supporting C1X implement the optional
<threads.h> (which duplicates facilities already in POSIX, but with different
interfaces), __STDC_NO_THREADS__ should be predefined (for the whole
translation unit), but users should still be able to use an add-on or
third-party implementation of these functions which should be able to cause
this macro to be undefined (for the whole translation unit) when the -I option
pointing to its headers is passed. And hardcoding knowledge in GCC that a
particular library feature is unsupported seems like a bad idea since it may
not always be unsupported.
* The optional Annex K (formerly TR 24731-1) will presumably also not be
implemented in glibc (in general those functions are of very dubious design and
utility), but again it should be possible for an add-on or separate
implementation to provide implementation of the functions and wrapper headers,
and to cause __STDC_LIB_EXT1__ to be defined when the appropriate -I option is
passed.
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.