Le 1 nov. 2016 12:18, "Thomas Wiens" a écrit :
>
> On 01.11.2016 12:05, Pascal Quantin wrote:
>
> > Why not simply select the right function based on ft type? For
FT_(U)INT40
> > and above use the functions I indicated earlier.
>
> Now someone can use a value_string inside a bitmask field, even if
On 01.11.2016 12:05, Pascal Quantin wrote:
> Why not simply select the right function based on ft type? For FT_(U)INT40
> and above use the functions I indicated earlier.
Now someone can use a value_string inside a bitmask field, even if the
type FT_UINT64 is used.
If I change it so you have to u
Le 1 nov. 2016 11:47, "Thomas Wiens" a écrit :
>
> On 31.10.2016 17:02, Pascal Quantin wrote:
>
> > Looks like no one is currently working on it (or at least no patch is
> > queued in Gerrit yet). As you seem to be the fist user of those
functions
> > with 64bits fields, you are probably a good ca
On 31.10.2016 17:02, Pascal Quantin wrote:
> Looks like no one is currently working on it (or at least no patch is
> queued in Gerrit yet). As you seem to be the fist user of those functions
> with 64bits fields, you are probably a good candidate to submit a patch as
> you can easily test it ;)
>
Hi Thomas,
2016-10-31 16:41 GMT+01:00 Thomas Wiens :
> On 31.10.2016 11:53, Thomas Wiens wrote:
> > On 31.10.2016 08:10, Pascal Quantin wrote:
> >
> >> Because we overlooked this. I intended to change it today but Guy was
> >> faster than me. Nightly master-2.0, master-2.2 and master builds shoul
On 31.10.2016 11:53, Thomas Wiens wrote:
> On 31.10.2016 08:10, Pascal Quantin wrote:
>
>> Because we overlooked this. I intended to change it today but Guy was
>> faster than me. Nightly master-2.0, master-2.2 and master builds should
>> behave properly. If you need to use a stable released versi
On 31.10.2016 08:10, Pascal Quantin wrote:
> Because we overlooked this. I intended to change it today but Guy was
> faster than me. Nightly master-2.0, master-2.2 and master builds should
> behave properly. If you need to use a stable released version, then you
> need to create the tree and sub e
2016-10-30 23:32 GMT+01:00 Thomas Wiens :
> On 30.10.2016 22:52, Pascal Quantin wrote:
>
> > When looking at proto_item_add_bitmask_tree() it looks like
> > proto_tree_add_uint64() is called both for FT_UINT64 and ft_INT64 (which
> > seems surprising, not to say wrong). Until this gets clarified,
On 30.10.2016 22:52, Pascal Quantin wrote:
> When looking at proto_item_add_bitmask_tree() it looks like
> proto_tree_add_uint64() is called both for FT_UINT64 and ft_INT64 (which
> seems surprising, not to say wrong). Until this gets clarified, you might
> get more success by manually creating th
On 30.10.2016 22:54, Guy Harris wrote:
> But you said it was a 64-bit unsigned integer:
>
> { "Error code", "s7comm-plus.returnvalue.errorcode", FT_UINT64, BASE_HEX,
> NULL, 0x,
>NULL, HFILL }},
>
> Try saying it's a 16-bit signed integer - FT_INT16 - instead.
Does not wor
On Oct 30, 2016, at 2:39 PM, Thomas Wiens wrote:
> 1) It seems to be impossible to decode a value inside the bitmask as
> signed integer
>
> The "Error code" value should be 16 bit signed integer.
But you said it was a 64-bit unsigned integer:
{ "Error code", "s7comm-plus.returnvalue.errorcod
Hi Thomas,
2016-10-30 22:39 GMT+01:00 Thomas Wiens :
> Hi,
> I'm working on a protocol where I want to use proto_tree_add_bitmask for
> a 64 Bit value.
> You can see the structure in the attached screenshot.
> This are my hf definitions (1st one is the header, the other ones are
> the fields):
>
Hi,
I'm working on a protocol where I want to use proto_tree_add_bitmask for
a 64 Bit value.
You can see the structure in the attached screenshot.
This are my hf definitions (1st one is the header, the other ones are
the fields):
{ &hf_s7commp_data_returnvalue,
{ "Return value", "s7comm-plus.ret
13 matches
Mail list logo
