Reviving `inout` parameter support.

[cleeland]

I recently discovered some unfinished work you started to support display of inout parameters, and filed this issue at juan cespedes' upstream project. The orphaned work obviously targeted an older design, pre-"lens", so I am working on porting it forward manually ("spiritual rebase" as a colleague calls it).

I"m currently porting it commit-by-commit atop 31af32c, which is the commit that introduces lenses. The only documentation I can find on "lenses" is in the conf file man page. Is there anything further, at a developer or architecture level? I'm wondering if out and inout could be a lens rather than an additional decorator, eg., for a call that takes a struct something* as a first argument, and modifies it (i.e., an inout argument),

struct something;
void performAction(inout(struct something*));

That would cause the value to be rendered on the way in and on the way out. Such behavior is useful for this pointers and synthetic pseudo-this pointers as is found in oo-ish C style APIs.

Would really appreciate any feedback you're willing to offer.

[pmachata]

Hi Chris! I haven't been active in ltrace for like 8, 9 years now, so take what I say below with a grain of salt. Chris Cleeland <notifications@github.com> writes:

I recently discovered some unfinished work you started to support display of `inout` parameters, and filed [this issue at juan cespedes' upstream project](https://gitlab.com/cespedes/ltrace/-/issues/5). The orphaned work obviously targeted an older design, pre-"lens", so I am working on porting it forward manually ("spiritual rebase" as a colleague calls it).

Yeah, this does not look finished, I think even back then I would have split the patches more reasonably. I would say don't waste time porting and just write it anew, honestly. There might be bits and pieces of value to extract from the patches, but I'm doubtful. It's just a hodgepodge of random code dumps.

I"m currently porting it commit-by-commit atop 31af32c, which is the commit that introduces lenses. The only documentation I can find on "lenses" is in the conf file man page. Is there anything further, at a developer or architecture level? I'm wondering if `out` and `inout` could be a lens

Code is king, pretty much. The ltrace object model concepts are reasonably close to the user level, so whatever you glean from the man pages is pretty much how the thing is modeled in-code.

rather than an additional decorator, eg., for a call that takes a `struct something*` as a first argument, and modifies it (i.e., an inout argument), ``` struct something; void performAction(inout(struct something*)); ``` That would cause the value to be rendered on the way in and on the way out. Such behavior is useful for `this` pointers and synthetic pseudo-this pointers as is found in oo-ish C style APIs.

Neat. That could work. I like it. There is currently a "hide" lens, which hides the argument unconditionally, so evidently something like this would work in principle. An in argument would have an in-lens as something, and out-lens as hide. An out argument would be vice versa. Inout would just have the same lens in both directions. A tail of hide lenses could be optimized out so that ltrace doesn't waste time ptracing unnecessary stuff out of the image. I wonder if it makes sense to be able to set two types of lenses, one for in direction and the other for the out direction. I think inout et.al. need to be able to take another lens as an argument: int foo(inout(string)); Since string is treated as string(array(char, zero)*) and therefore itself involves a lens. I'm not sure how composable lenses currently are. So that's something that might require some extending.

Would really appreciate any feedback you're willing to offer.

Note that I don't think there is any real upstream. Juan Cespedes has not been very active as long as I remember. I think DJ Delorie maintains ltrace in Red Hat, and he may be the closest thing to an upstream that there currently is. Anyway, if you have any code, I'm happy to review it, for whatever such review is worth after all those years :)