RFC: libkern version of inet_ntoa_r

Arnaud Lacombe lacombar at gmail.com
Sun Jul 29 22:30:23 UTC 2012


Hi,

On Sun, Jul 29, 2012 at 4:30 PM, Lev Serebryakov <lev at freebsd.org> wrote:
> Hello, Luigi.
> You wrote 30 июля 2012 г., 0:47:21:
>
>>> #define fn(x)   ({ fn(x, 42); })
> LR> nice trick, one always learns something on these lists...
> LR> now i wonder how it works with MSVC (windows being one of the
> LR> other platforms where i need to build the ipfw+dummynet code...)
>  It looks very gcc-ish.
>
could you back your point with a technical argument, please ? This
sounds rather FUD'ish so far.

The ({ ... }) is nothing more than a primary-expression enclosing a
compound-statement; this part is not specifically necessary. As for
the expansion, I would assume the following part of iso9899:1999
applies:

<<
6.10.3 Macro replacement

10
A preprocessing directive of the form

# define identifier lparen identifier-listopt ) replacement-list new-line
# define identifier lparen ... ) replacement-list new-line
# define identifier lparen identifier-list , ... ) replacement-list new-line

defines a function-like macro with arguments, similar syntactically to
a function call. [...] Each subsequent instance of the function-like
macro name followed by a ( as the next preprocessing token introduces
the sequence of preprocessing tokens that is replaced by the
replacement list in the definition (an invocation of the macro). The
replaced sequence of preprocessing tokens is terminated by the
matching ) preprocessing token, [...]
>>

Note that the standard say "Each subsequent", no "All", so

fn(1, 2);
#define fn(a) fn(a, 2)
fn(1);

would produces:

fn(1, 2);

fn(1, 2);

I do not see any gcc'ism here.

Now, I might be wrong, and would enjoy being proven so.

Thanks,
 - Arnaud


More information about the freebsd-current mailing list