[David Aggeler <david_aggeler@xxxxxxxxxx>]

Indeed proto_tree_add_int_xxx() now rejects, when the signed/unsigned declaration (gint/guint)
of the 'value' does not match the hf declaration (FT_INT & FT_UINT). This is the case for 16 & 32 bit data types.
I was not mixing value length.

It is good to be restrictive with types. However, I do not consider such a late detection at runtime very efficient.
It only occurred in a few captures. I would prefer new function calls to separate signed/unsigned/16/32 bit ints,
so the compiler could catch it. Hopefully I'm the last one to run into this situation.

Thanks
David

Joerg Mayer wrote:

On Thu, Nov 12, 2009 at 10:58:35PM +0100, David Aggeler wrote:
  

I now have the latest 1.2 and the latest 1.3 SVNs in parallel use. with 
the exact same copy of packet-dcm.c.
In 1.2 things behave as expected (both with 1.2 and 1.3 version 
packet-dcm.c).

In 1.3 I had yesterday:
- Debugging problems in MSEE (function is terminated somewhere in the 
middle)
- Setting a simple int in a structure causes a crash (heap error)
I'd usually contribute this to accessing deallocated memory, but why 
does the same thing work in 1.2? I'd also say, that about two month ago, 
I did not see this in 1.3.

Today I get an a DISSECOTOR_ASSERT_NOT_REACHED in a super simple 
proto_tree_add_int_format()
tvb is 28670 bytes long, the offset is only 622 and I'd like to mark 4 
bytes.

Is this to be expected with coding work going on?
    

There is one thing that may have changed between 1.2 and 1.3:
Maybe the type in the hf field is no longer acceptable. The
required field types are checked more strictly in 1.3.

HTH

   Joerg