"afll" needs a JSON output

[EmilyBragg]

When getting function information, "aflj" will get the basic information in JSON format, but there is no corresponding "afllj" (I think it's actually a bug, as "afllj" returns the same string as "afll").

[Maijin]

I think this is afij on every functions

[EmilyBragg]

afij has most of the same information, but certainly not all of it. It can be recreated from other functions, but if I want the information from afll, I currently have to parse it out (which is at least mildly a hassle given that there are spaces in the header, so it can't just be split on spaces or tabs). It's low priority because it's a minor feature (ensuring that json output is available across the board) to be sure.

[Maijin]

Which info from afij is missing from afll ?

[EmilyBragg]

I'm using afll to pull the function names and bounds (as 'afll' provides the min and max bounds). afij doesn't have the min/max bounds. I know they can be calculated from other commands, but at least for getting a high-level overview of functions and memory locations, afll has the information I want, without an easy way to use it through r2pipe without doing all the string parsing (and hoping that the string format doesn't change later, etc)

[Maijin]

@radare thoughts?

[radare]

We should do the afllj

On 1 May 2017, at 17:50, Maijin notifications@github.com wrote:

@radare thoughts?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Maijin]

What will be difference

[radare]

more verbose. imho its useful to have different levels of verbosity in the json files we generate because that allows frontend to grab more rows in less time and make the data more manageable for some frontends and avoid unnecessary clutter. most of the time ppl just want to know where the functions start and its name, this is aflqj for example

On 02 May 2017, at 14:40, Maijin notifications@github.com wrote:

What will be difference

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/radare/radare2/issues/7339#issuecomment-298623700, or mute the thread https://github.com/notifications/unsubscribe-auth/AA3-lqFg-H4JgkCmoO0nLV2oDs3PeZ0Cks5r1yQ8gaJpZM4NEjtV.

[giuscri]

I might be able to work on that.

Right now afll and aflj lead to fcn_list_verbose() and fcn_list_json() respectively.

Should I add a function fcn_list_verbose_json() and make the switch at libr/core/canal.c as the following?

@@ -2255,7 +2255,11 @@ R_API int r_core_anal_fcn_list(RCore *core, const char *input, const char *rad)
                r_core_anal_fcn_list_size (core);
                break;
        case 'l':
-               fcn_list_verbose (core, fcns);
+               if (rad[1] == 'j') {
+                       fcn_list_verbose_json (...);
+               } else {
+                       fcn_list_verbose (core, fcns);
+               }
                break;
        case 'q':
                if (rad[1] == 'j') {

[giuscri]

I've noticed that aflj gives more information than afl.

Shouldn't aflj gives the same detail of afl? Or, shouldn't aflj gives all the information given by afll — making afllj an alias aflj?

In the first case, I would write fcn_print_json() and fcn_print_verbose_json() reducing the amount of information printed by fcn_print_json.

In the second case, missing information would be added infcn_print_json().

I would vote for the second case, as that would not break current expectations from users of aflj.

[Maijin]

Send a Pull Request please https://help.github.com/articles/about-pull-requests/ not diff

[giuscri]

I didn't implement anything, just sketched the interface

[radare]

I would prefer a single aflj . Having multiple json representations is a bit problematic and may confuse users. The only reason is imho having a quiet json format to get quick listing of all the functions qhen the list is ultra large

On 4 Feb 2018, at 15:18, Giuseppe notifications@github.com wrote:

I've noticed that aflj gives more information than afl.

Shouldn't aflj gives the same detail of afl? Or, shouldn't aflj gives all the information given by afll — making afllj an alias aflj?

In the first case, I would write fcn_print_json() and fcn_print_verbose_json() reducing the amount of information printed by fcn_print_json.

In the second case, missing information would be added infcn_print_json().

I would vote for the second case, as that would not break current expectations from users of aflj.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[radare]

We can call aflj from afllj if u want

On 4 Feb 2018, at 17:32, Giuseppe notifications@github.com wrote:

I didn't implement anything, just sketched the interface

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.