RE: [lwip-devel] [bug #3031] Implement a newfullypool-basedpbufimplementation.

[Grubb, Jared]

No, the difference was in the "len //no semicolon" line... but that does
not compile properly. I had thought that leaving the semicolon off
causes the block of code to evaluate to the statement without the
semicolon. But, I think that's not a standard C feature (For example
MSVC++ doesn't let you have {} inside of evaluations... I just tried it
hehe)

The problem is that you NEED the {} in order to create a new scope so
you can create a new variable. In that case, you cannot do what you want
in a macro. You could do it in an inline function.

If you want a return value from a macro then you can use commas, but you
get no scope changing ability:

// Suppose STUPIDMACRO does: (yeah it's C++ ref, but this is just a
comment)
//   int stupid_macro_fcn(int& a, int& b) {a++; b++; return (a+b);}
#define STUPIDMACRO(a,b)  (a++, b++, a+b)

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of
Goldschmidt Simon
Sent: Wednesday, July 25, 2007 11:18 PM
To: lwip-devel
Subject: RE: [lwip-devel] [bug #3031] Implement a
newfullypool-basedpbufimplementation.


> I haven't compiled it, but doesn't this do it:
> 
> #define pbuf_clen(p, len) \
> { \
>   struct pbuf *q = (p); \
>   (len) = 0; \
>   while (q != NULL) { \
>     ++(len); \
>     q = q->next; \
>   }\
>   len    // no semicolon!
> }

That's the same as my version, isn't it? The problem is it should be
#define pbuf_clen(p) and _return_ len, to be compatible to the existing
function.

Since it only is used in tcp_in.c, we could maybe create a new define to
use in tcp_in.c and leave the function exist like it is, for application
Compatibility?


Simon


_______________________________________________
lwip-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-devel