On Sun, 28 Mar 2021, Markus Elfring wrote:

> > If you find that something does not work satisfactorily, propose a
> > semantic patch and show what doesn't work.
>
> @display@
> @@
> *#define

Obviously this doesn't work.  Just like

@@
@@
*if

doesnt' work.

> > I'm not going to try to solve a problem when I don't know what the problem is.
>
> Another SmPL script example:
>
> @display2@
> identifier i;
> expression e;
> @@
> *#define i e
>
>
> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch show_define_usage2.cocci /usr/include/pipewire-0.3/pipewire/client.h
> …
> -#define PW_CLIENT_EVENT_INFO		0
> …

And what is the problem here?

>
>
> > I think that this tranformation would be diffficult to make using Coccinelle,
>
> * I imagine also that it can be challenging to determine which preprocessor identifiers
>   can really be converted to enumerations.
>
> * My programmer eyes were trained for some pattern recognition.
>   https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/981
>   https://github.com/issues?q=is%3Aissue+author%3Aelfring+%22+enum%22
>
>
> > due to the need to ensure that the enum values are end up in the
> > right order, if you want to rely on the implicit values of enums.
>
> I am looking again for the application of algorithms according to
> longest common text (or prefixes) in used symbols.

This may (or may not) give you the right grouping, but you will still have
to ensure that the elements end up in the right order, unless you want to
provide all the values explicitly.

>
> > Furthermore, if this is targeting C code, the benefits will be limited,
> > because C considers enums to be the same as ints.
>
> * Will such a transformation help with software debugging?

Not likely, because the compiler provides no support and the definitions
are typically far from the uses.

julia

>
> * Would you like to reuse another named data type?
>
> Regards,
> Markus
>