[Wireshark-dev] SET_ADDRESS, if-else

2013-09-07 Thread Martin Kaiser
Hi,

I just found that

if (...)
   SET_ADDRESS(...);
else
   SET_ADDRESS(...);

does not compile as this would expand to

if (...)
{
};
else
{
}

and the compiler complains about else without if.

Is there anything useful we could do about this other that putting
another pair of brackets around the first SET_ADDRESS?

Regards,
Martin
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] SET_ADDRESS, if-else

2013-09-07 Thread Gerald Combs
On 9/7/13 5:53 AM, Evan Huus wrote:
 The usual trick in this situation is to wrap the macro in a do { MY
 CODE } while (0) so that it behaves syntactically like a normal
 function call. I have done this in r51819, so it should work now.

Is there any reason we shouldn't convert the macros in address.h (and
proto.h and packet.h and ...) to inline functions?
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe


Re: [Wireshark-dev] SET_ADDRESS, if-else

2013-09-07 Thread Evan Huus
On Sat, Sep 7, 2013 at 12:46 PM, Gerald Combs ger...@wireshark.org wrote:

 On 9/7/13 5:53 AM, Evan Huus wrote:
  The usual trick in this situation is to wrap the macro in a do { MY
  CODE } while (0) so that it behaves syntactically like a normal
  function call. I have done this in r51819, so it should work now.

 Is there any reason we shouldn't convert the macros in address.h (and
 proto.h and packet.h and ...) to inline functions?


No objections from me. I tried tracing some of them back through git and
got lost around 2004, so I don't actually know if there was a reason to
make them macros at the time (whenever that was).
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] SET_ADDRESS, if-else

2013-09-07 Thread Guy Harris

On Sep 7, 2013, at 9:46 AM, Gerald Combs ger...@wireshark.org wrote:

 On 9/7/13 5:53 AM, Evan Huus wrote:
 The usual trick in this situation is to wrap the macro in a do { MY
 CODE } while (0) so that it behaves syntactically like a normal
 function call. I have done this in r51819, so it should work now.
 
 Is there any reason we shouldn't convert the macros in address.h (and
 proto.h and packet.h and ...) to inline functions?

The only reason to would be caring about compilers that don't handle inline 
functions, but that may be significantly less important now than when the code 
was originally written, as more of the compilers with which Wireshark can be 
compiled probably now support inline functions.

According to


https://developer.gnome.org/glib/stable/glib-Miscellaneous-Macros.html#G-INLINE-FUNC:CAPS

...inline is already declared in a portable manner in the GLib headers and can 
be used normally., so if some compiler uses something *other* than just 
inline (e.g., __inline, as I think some compilers with which we compile 
do), inline gets defined appropriately.

Presumably they'd be static inline.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe