On Sat, Jun 17, 2017 at 04:06:50PM +0300, Dmitry V. Levin wrote:
> On Sat, Jun 17, 2017 at 08:55:29PM +0800, JingPiao Chen wrote:
> > On Sat, Jun 17, 2017 at 03:27:30PM +0300, Dmitry V. Levin wrote:
> > > On Sat, Jun 17, 2017 at 07:18:29PM +0800, JingPiao Chen wrote:
> > > > On Sat, Jun 17, 2017 at 12:35:15AM +0300, Dmitry V. Levin wrote:
> > > > > On Sat, May 20, 2017 at 07:42:19PM +0800, JingPiao Chen wrote:
[...]
> > > This is better, but yet you'd create two different parsers
> > > for NLA_U64 and NLA_MSECS which are identical.
> > >
> > > Would it be better if we introduced functions for parsing each nla
type?
> >
> > I prefer to introduced functions for parsing each nla type,
> > Like this:
> >
> > typedef (*nla_decoder_t)(struct tcb *,
>
> Do not forget about the return code type.
>
> > kernel_ulong_t addr,
> > kernel_ulong_t len,
> > void *opaque_data);
> > static const nla_decoder_t unix_nla_decoders[] = {
> > [UNIX_DIAG_PEER] = decode_nla_u32,
> > [UNIX_DIAG_ICONS] = decode_unix_diag_icons
> > };
>
> Go ahead then. :)
Ok, I will send to mailing list after I fixed. Thank you.
--
JingPiao Chen
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
