[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141013180056.GA28588@zx-spectrum.accesssoftek.com>
Date: Mon, 13 Oct 2014 21:00:56 +0300
From: Sergey Dmitrouk <sdmitrouk@...esssoftek.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: [PATCH] Convert some is* macros to inline functions
On Mon, Oct 13, 2014 at 07:35:14AM -0700, Jens Gustedt wrote:
> Am Montag, den 13.10.2014, 17:20 +0300 schrieb Sergey Dmitrouk:
> In section 7.1.4 the C standard explicitly says:
>
> > Any function declared in a header may be additionally implemented
> > as a function-like macro defined in the header, ...
Didn't look there, you're right. I was checking description of headers
instead.
> > Please find the attached patch that proposes replacing these macros
> > with inline functions.
>
> I don't think that this is necessary.
>
> They only advantage of inline functions, here would be that the
> conversion of the arguments would be done with implicit conversions
> instead of casts. (For the macros this could be achieved by using
> compound literals instead of casts, but well...)
It's not necessary for C (as I know now), but it's required by ะก++
standard in 17.6.1.2:
> Names that are defined as functions in C shall be defined as functions
> in the C++ standard library. 175)
> 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.
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.
Regards,
Sergey
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
