Advanced and improved absolute paths decoding

[eQuiNoX]

On Thu, Mar 6, 2014 at 8:01 PM, Philippe Ombredanne
<pombredanne at nexb.com> wrote:
> On Tue, Mar 4, 2014 at 1:59 PM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
>> Hey Philippe,
>>
>>> Just curious, why would you use call_one? and arg1,arg2 v.s using  lists?
>>
>> I was just wondering if information related to the call sequence might
>> be useful. In quite a few languages, JSON data directly maps to
>> dictionary representations(eg:- Python) -- but upon doing that we'd
>> lose information about the sequence in which the calls occurred once
>> we create a dictionary from the JSON. In such cases having explicit
>> information about the order might be useful.
>
> JSON is a spec so you should not care about how it is interpreted in a
> given language.
> JSON has arrays that are ordered lists and objects that are unordered
> name/value mappings.
> So when you need an ordered sequence, use an array, please do not make
> up a map name to track ordering.
> If you have name/values mapping and need ordering, wrap that in an array.

Good point, yes, I agree.


>
>
>>> FWIW the above would not be valid JSON.
>>> What about something like:
>>> [
>>>   {"fnname": "open",
>>>    "args":  ["/usr/lib/locale/UTF-8/LC_CTYPE", "O_RDONLY|O_CLOEXEC"],
>>>    "ret": "-1"
>>>   }
>>> ]
>>
>> Cool stuff, thank you!
>>
>>>
>>> or possibly (not sure which form I like best) using a more compact
>>> entirely and positional list of lists:
>>> [
>>>     "open",
>>>     "-1",
>>>    [
>>>         "/usr/lib/locale/UTF-8/LC_CTYPE",
>>>         "O_RDONLY|O_CLOEXEC"
>>>     ]
>>> ]
>>>
>>>> Of course, this above example is oversimplified(And I'm not sure thats
>>>> the best way to manage quoting to be honest, I'll put in some more
>>>> thought).
>>
>> I think I like the first one better, I think it looks cleaner(open to
>> suggestions of course!).
>
> I do not know which one is better yet but a simpler array without
> made-up names when they do not exist feels much cleaner and less
> verbose to me, and does not affect the structure nor the readability.
> Being somewhat compact is not something nice to have but a feature
> when tracing IMHO both in terms of time and space.

Indeed, I hadn't considered that.

>
>>> I think that in the case of a JSON output, double quoting paths would
>>> not be desirable and paths should be returned a simple JSON string
>>
>> Cool stuff, makes sense.
>>
>>>
>>>> In cases where a struct is passed as an argument, as in the case of a
>>>> bind call we have,
>>>> bind(3, {sa_family=AF_INET, sin_port=htons(7171),
>>>> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>>>>
>>>> We could have "arg2" set to "{sa_family=AF_INET, sin_port=htons(7171),
>>>> sin_addr=inet_addr("0.0.0.0")}" but I feel it defeats the purpose as
>>>> parsing output itself would be more painful. Perhaps something like
>>>> the following would be nice.
>>>>
>>>> {
>>>>    "call_thirteen" : {
>>>>       "fnname" = "bind",
>>>>       "arg1"     = "3",
>>>>       "arg2"     : {
>>>>             "sa_family" : "AF_INET",
>>>>             "sin_port" : "htons(7171)",
>>>>             "sin_addr" : "inet_addr("0.0.0.0")"
>>>>        },
>>>>        "ret"       = "-1"
>>>>    }
>>>> }
>>>
>>> This makes sense but same comment as above: why not using a combo of
>>> objects and arrays (using JSON speak)?
>>> and why not structuring everything that can be?
>>> ie something along these lines?
>>> [
>>>     {
>>>         "fnname": "bind",
>>>         "args": [
>>>             "3",
>>>             {
>>>                 "sa_family": "AF_INET",
>>>                 "sin_port": {
>>>                     "htons": "7171"
>>>                 },
>>>                 "sin_addr": {
>>>                     "inet_addr": "0.0.0.0"
>>>                 }
>>>             }
>>>         ],
>>>         "ret": "-1"
>>>     }
>>> ]
>>
>> If the call information being added makes sense, it would look
>> something as follows, I believe :-
>>
>> '{"call_one": [{"fnname": "bind", "ret": "-1", "args": ["3",
>> {"sin_port": {"htons": "7171"}, "sin_addr": {"inet_addr": "0.0.0.0"},
>> "sa_family": "AF_INET"}]}]}'
>
> As I said above adding call_one does not make sense and is rather
> ugly. Use arrays/list not maps/objects for sequences.
> The top level construct should therefore be a list [] not a map.
> Where you need a sequence, use a list. And use a map only when needed.
> Do not make up names.

Perfect, sounds good to me! I'll modify my GSoC proposal to reflect
these changes, thank you!


Thanks!
zm