Derive Named

[riesentoaster]

A lot of structs within LibAFL implement Named. And all of those are done manually, leading to a lot of code duplication. Would it make sense to create a derive macro that implements it based on the struct name?

Is there a reason this doesn't exist already?

[tokatoka]

Contrary to what the code is now, I think we should not directly use the struct name for its name.
because they could cause name collision if they use the names for lookups of the metadatas
Each type of struct should have monotonously increasing counter and the name should be <struct name>_<counter id>

If derived macro can do that then it's good to have

[tokatoka]

are you interested in implementing this?

[riesentoaster]

That is a fair point.

It may however be hard to implement:

1. It'd need some form of synchronisation across clients since they may not run in the same memory space. Alternatively, we can also just say that we're only interested in names unique to a client and ignore this problem.
2. Having unique names is something that should be enforced by the architecture, wrong implementations should not be possible. This has some consequences for the creation process:
   • It would mean that every struct implementing Named would own a Cow<'static, str> with its name. Adding parts to a struct in a macro is pretty straight-forward I believe (although I have little experience).
   • The name would need to be generated when the struct is created, thus changing code in new functions and such. And that is really hard to do programmatically, since this code is not uniform at all.

If I read the code correctly, Named is exclusively used for handles (Handled), right? If that is true I'm wondering if there is a better, built-in, way to identify structs instead of relying on manual implementations.

[riesentoaster]

Even just implementing the bare minimum of this however seems like a lot of work, and I don't have the capacity to do so at the moment.

There is still a point to be made that a macro that just implements Named as follows is progress, since it removes code duplication and we decouple the implementation of Named from the specific struct. This way, if we ever want to change how this is handled, we can do so without changing all the structs again.

impl Named for MyNamedThing {
    fn name(&self) -> &Cow<'static, str> {
        &Cow::Borrowed("MyNamedThing")
    }
}

[tokatoka]

It'd need some form of synchronisation across clients

For this one, the name can just be local to the process. no need to synchronize

[riesentoaster]

There is still a point to be made that a macro that just implements Named as follows is progress, since it removes code duplication and we decouple the implementation of Named from the specific struct. This way, if we ever want to change how this is handled, we can do so without changing all the structs again.

impl Named for MyNamedThing {
    fn name(&self) -> &Cow<'static, str> {
        &Cow::Borrowed("MyNamedThing")
    }
}

Do you want this for now?

[domenukk]

I think we'd want to create a self.name with name being MyNamedThing if an atomic counter is 0, and MyNamedThing2 if the conuter is > 0
So every created instance has a unique name...

[riesentoaster]

I think we'd want to create a self.name with name being MyNamedThing if an atomic counter is 0, and MyNamedThing2 if the conuter is > 0

That would be the optimal way, but it's only possible in the most trivial cases. The issue is that I need to be able to automatically derive all constructor functions for the struct as well, to be able to create an additional struct part containing the structs unique name. So this reasonably only works for constructors where all struct items are passed to the constructor and directly stored in the struct, without any additional logic (because that cannot generally be derived).

I'm not sure the added code complexity is worth it for a solution that only works for a limited subset of targeted structs.