Re: RFC: libkern version of inet_ntoa_r

Hi,

On Sun, Jul 29, 2012 at 4:30 PM, Lev Serebryakov <lev@freebsd.org> wrote:
> Hello, Luigi.
> You wrote 30 =D0=B8=D1=8E=D0=BB=D1=8F 2012 =D0=B3., 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-lin=
e

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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"