Hi,
Yes FT_NSTRING would be great.
I have a lot of fiddly code like below that drives me crazy.
<snip>
agw_str_length = octet1; /* grab length */
proto_tree_add_string_format(agwlite_tree,
hf_agwlite_agwname,
tvb, offset, agw_str_length,
tvb_get_ptr(tvb, offset, agw_str_length),
"AGW Name: %.*s", /* neat trick with .*s */
agw_str_length,
tvb_get_ptr(tvb, offset, agw_str_length));
<snip>
I will gladly test it out for you :-)
Cheers / Frank..
Gilbert Ramirez wrote:
>
> On Fri, Jul 14, 2000 at 09:14:38AM -0500, Craig Rodrigues wrote:
> >
> >
> > Hi,
> >
> > I would like to give a shot at enhancing the packet-giop.c
> > dissector for CORBA IIOP. I was wondering, what technique
> > do people use in the other dissectors for dealing with
> > variable length data structures? For example, IIOP
> > defines a string which is represented by it's length n, followed
> > by n + 1 bytes which contain the actual string (with other encoding
> > schemes for wide characters). Is there a glib structure that I can
> > use? I'm a bit lazy to do all the memory management by myself. :)
>
> Funny you should ask... I just mentioned the necessity for an FT_NSTRING
> field type, for a string with a prefixed byte representing the length.
>
> Do you have to actually manipulate the string (that is, put it into
> a C variable and do something with it), or do you only have to put
> it into the protocol tree? (in which case, the existence of
> FT_NSTRING would solve your problem, w/o the need of anything in glib).
>
> --gilbert
--
EUS/GN/V/Z Frank Singleton ASO Americas BSS
Office : +1 972 583 3251 ECN 800 33251
Pager : +1 800 651 1184 Email : eusfrsi@xxxxxxxxxxxxxxx
Amateur Radio: VK3FCS/KM5WS Email : frank.singleton@xxxxxxxxxxxx
Hardware: HP Omnibook 4150 running Redhat Linux 6.2 (2.2.16 kernel).