mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Szabolcs Nagy <nsz@port70.net>
To: musl@lists.openwall.com
Subject: Re: [PATCH] Convert some is* macros to inline functions
Date: Mon, 13 Oct 2014 20:49:56 +0200	[thread overview]
Message-ID: <20141013184956.GA4874@port70.net> (raw)
In-Reply-To: <20141013180622.GE32028@brightrain.aerifal.cx>

* Rich Felker <dalias@libc.org> [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 <header.h>, 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 <c_____> 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 <cname> headers
and then defines the semantics for the <name.h> headers in terms of
the <cname> 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 <iso646.h> or
    <ciso646> 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).


  reply	other threads:[~2014-10-13 18:49 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-13 14:20 Sergey Dmitrouk
2014-10-13 14:35 ` Jens Gustedt
2014-10-13 18:00   ` Sergey Dmitrouk
2014-10-13 18:06     ` Rich Felker
2014-10-13 18:49       ` Szabolcs Nagy [this message]
2014-10-14  9:01         ` Sergey Dmitrouk
2014-10-14 16:34           ` 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=20141013184956.GA4874@port70.net \
    --to=nsz@port70.net \
    --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).