[Wireshark-dev] Please backport
I think the following patch should be backported (but didn't flag it at the time). The problem will only hit core developers that use svn 1.7. r51566 | jmayer | 2013-08-28 20:27:16 +0200 (Mi, 28 Aug 2013) | 4 lines svn version 1.7.11 no longer has local .svn directories, just one at the top level. So on my system, /trunk no longer contains a .svn directory. Check in parent directory as well. Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ 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
[Wireshark-dev] reported_length -1
Dear all, I stumbled on tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb, 1) - 2)); If tvb_get_guint8(tvb, 1)==0, we throw an exception because of backing_length - that makes sense. As for reported_length-1, it looks like that's ok when the tvb is created. There'll be an exception when it's accessed, we'll always be out of bounds. Is there a valid use case for reported_length-1? Thanks, 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] reported_length -1
2013/9/7 Martin Kaiser li...@kaiser.cx Dear all, I stumbled on tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb, 1) - 2)); If tvb_get_guint8(tvb, 1)==0, we throw an exception because of backing_length - that makes sense. As for reported_length-1, it looks like that's ok when the tvb is created. There'll be an exception when it's accessed, we'll always be out of bounds. Is there a valid use case for reported_length-1? I Martin, I (wrongly?) assumed that it would automatically throw an exception (as I found at least one other code line like this in the source tree) so I did not add an explicit check on the size before creating the tvb. I do not see any valid use case either. Pascal. ___ 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] reported_length -1
Hi Pascal, Thus wrote Pascal Quantin (pascal.quan...@gmail.com): 2013/9/7 Martin Kaiser li...@kaiser.cx tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb, 1) - 2)); As for reported_length-1, it looks like that's ok when the tvb is created. There'll be an exception when it's accessed, we'll always be out of bounds. Is there a valid use case for reported_length-1? I Martin, I (wrongly?) assumed that it would automatically throw an exception (as I found at least one other code line like this in the source tree) so I did not add an explicit check on the size before creating the tvb. I do not see any valid use case either. my mistake. The code of tvb_new_subset() does throw an exception also for reported_length -1. 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
[Wireshark-dev] SET_ADDRESS, if-else
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] reported_length -1
Hi folks, Sorry for hijacking the thread, but come to think of it, would it make more sense to test if it's 0, rather than testing for !=0? Tyson. 2013/9/7 Martin Kaiser li...@kaiser.cx Dear all, I stumbled on tvb_new_subset(tvb, 10, (tvb_get_guint8(tvb, 1) - 2), (tvb_get_guint8(tvb, 1) - 2)); If tvb_get_guint8(tvb, 1)==0, we throw an exception because of backing_length - that makes sense. As for reported_length-1, it looks like that's ok when the tvb is created. There'll be an exception when it's accessed, we'll always be out of bounds. Is there a valid use case for reported_length-1? Thanks, 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 -- Fight Internet Censorship! http://www.eff.org http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon | 00447934365844 ___ 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] Please backport
On 09/07/2013 02:58 AM, Joerg Mayer wrote: I think the following patch should be backported (but didn't flag it at the time). The problem will only hit core developers that use svn 1.7. r51566 | jmayer | 2013-08-28 20:27:16 +0200 (Mi, 28 Aug 2013) | 4 lines svn version 1.7.11 no longer has local .svn directories, just one at the top level. So on my system, /trunk no longer contains a .svn directory. Check in parent directory as well. I added this to the list of revisions to be back-ported to 1.10.2 and 1.8.10. ___ 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
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
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
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
