From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6303 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH] Convert some is* macros to inline functions Date: Mon, 13 Oct 2014 20:49:56 +0200 Message-ID: <20141013184956.GA4874@port70.net> References: <20141013142020.GA26828@zx-spectrum.accesssoftek.com> <1413210914.4885.1174.camel@eris.loria.fr> <20141013180056.GA28588@zx-spectrum.accesssoftek.com> <20141013180622.GE32028@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1413226216 27759 80.91.229.3 (13 Oct 2014 18:50:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Oct 2014 18:50:16 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6316-gllmg-musl=m.gmane.org@lists.openwall.com Mon Oct 13 20:50:09 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Xdkh7-0006Jl-ET for gllmg-musl@plane.gmane.org; Mon, 13 Oct 2014 20:50:09 +0200 Original-Received: (qmail 7878 invoked by uid 550); 13 Oct 2014 18:50:08 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7870 invoked from network); 13 Oct 2014 18:50:08 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: <20141013180622.GE32028@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Xref: news.gmane.org gmane.linux.lib.musl.general:6303 Archived-At: * Rich Felker [2014-10-13 14:06:22 -0400]: > On Mon, Oct 13, 2014 at 09:00:56PM +0300, Sergey Dmitrouk wrote: > > Current headers do not conform to C++ when included as , and > > that's what I'm trying to fix. > > > > Would you consider a version that uses inline functions only when > > __cplusplus is defined? There is already 'extern "C"', so I guess it > > makes sense. > > Suppressing the macros for C++ would be acceptable if this is required > (it's not clear to me; my understanding was that it's only required > for the headers, not the <______.h> ones, and that the > wrappers for the former already take care of removing the macros). The > external inline functions are probably not acceptable; there are all > sorts of ugly issues with extern inline function support that I don't > want to deal with. only providig the macros #ifndef __cplusplus makes sense (but only do it in the 26 c headers the c++ standard talks about posix allows macro definitions for all functions in posix headers) the c++ standard could be more explicit about this incompatibility with c: it states the requirement in a note for the headers and then defines the semantics for the headers in terms of the one c++14 17.6.1.2 [headers] 4 Except as noted in Clauses 18 through 30 and Annex D, the contents of each header cname shall be the same as that of the corresponding header name.h, as specified in the C standard library (1.2) or the C Unicode TR, as appropriate, as if by inclusion. In the C++ standard library, however, the declarations (except for names which are defined as macros in C) are within namespace scope (3.3.6) of the namespace std. It is unspecified whether these names are first declared within the global namespace scope and are then injected into namespace std by explicit using-declarations (7.3.3). 5 Names which are defined as macros in C shall be defined as macros in the C++ standard library, even if C grants license for implementation as functions. [ Note: The names defined as macros in C include the following: assert, offsetof, setjmp, va_arg, va_end, and va_start. -- end note ] 6 Names that are defined as functions in C shall be defined as functions in the C++ standard library.^175 7 Identifiers that are keywords or operators in C++ shall not be defined as macros in C++ standard library headers.^176 8 D.5, C standard library headers, describes the effects of using the name.h (C header) form in a C++ program.^177 175) This disallows the practice, allowed in C, of providing a masking macro in addition to the function prototype. The only way to achieve equivalent inline behavior in C++ is to provide a definition as an extern inline function. 176) In particular, including the standard header or has no effect. 177) The ".h" headers dump all their names into the global namespace, whereas the newer forms keep their names in namespace std. Therefore, the newer forms are the preferred forms for all uses except for C++ programs which are intended to be strictly compatible with C. ... c++14 D.5 [depr.c.headers] 2 Every C header, each of which has a name of the form name.h, behaves as if each name placed in the standard library namespace by the corresponding cname header is placed within the global namespace scope. It is unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace std and are then injected into the global namespace scope by explicit using-declarations (7.3.3).