* [Cocci] Replacing #define directives with the help of SmPL @ 2021-03-28 7:19 Markus Elfring 2021-03-28 9:29 ` Julia Lawall 0 siblings, 1 reply; 16+ messages in thread From: Markus Elfring @ 2021-03-28 7:19 UTC (permalink / raw) To: Coccinelle Hello, Will the software development interests ever evolve in ways so that #define directives can be replaced with the help of the semantic patch language for special source code analysis and transformation approaches? https://github.com/coccinelle/coccinelle/issues/139 Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Replacing #define directives with the help of SmPL 2021-03-28 7:19 [Cocci] Replacing #define directives with the help of SmPL Markus Elfring @ 2021-03-28 9:29 ` Julia Lawall [not found] ` <1b5f6d22-5b89-097f-37bd-13b3b2ab011a@web.de> 0 siblings, 1 reply; 16+ messages in thread From: Julia Lawall @ 2021-03-28 9:29 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle On Sun, 28 Mar 2021, Markus Elfring wrote: > Hello, > > Will the software development interests ever evolve in ways so that #define directives > can be replaced with the help of the semantic patch language for special source code > analysis and transformation approaches? > https://github.com/coccinelle/coccinelle/issues/139 I looked at the link, but there is no concrete example of something that does not work, so I have no idea what the problem is. julia _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <1b5f6d22-5b89-097f-37bd-13b3b2ab011a@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <1b5f6d22-5b89-097f-37bd-13b3b2ab011a@web.de> @ 2021-03-28 10:47 ` Julia Lawall [not found] ` <173fa182-4127-aaba-262e-e3953a81a1e2@web.de> [not found] ` <eaa316bd-4c73-fcbb-bfad-20426348b1c2@web.de> 0 siblings, 2 replies; 16+ messages in thread From: Julia Lawall @ 2021-03-28 10:47 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1201 bytes --] On Sun, 28 Mar 2021, Markus Elfring wrote: > >> https://github.com/coccinelle/coccinelle/issues/139 > > > > I looked at the link, but there is no concrete example of something that > > does not work, so I have no idea what the problem is. > > You expressed another bit of better understanding of known limitations for > the Coccinelle software already, didn't you? > > Would you like to help any more with attempts to achieve support for > a transformation pattern like “#define ⇒ enum” according to the semantic patch language? > https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/981 > https://github.com/issues?q=is%3Aissue+author%3Aelfring+%22+enum%22 If you find that something does not work satisfactorily, propose a semantic patch and show what doesn't work. I'm not going to try to solve a problem when I don't know what the problem is. I think that this tranformation would be diffficult to make using Coccinelle, 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. Furthermore, if this is targeting C code, the benefits will be limited, because C considers enums to be the same as ints. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <173fa182-4127-aaba-262e-e3953a81a1e2@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <173fa182-4127-aaba-262e-e3953a81a1e2@web.de> @ 2021-03-28 11:46 ` Julia Lawall [not found] ` <b80fe77f-0a11-2000-522e-836c9368eaa6@web.de> ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Julia Lawall @ 2021-03-28 11:46 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1920 bytes --] 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 > [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <b80fe77f-0a11-2000-522e-836c9368eaa6@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <b80fe77f-0a11-2000-522e-836c9368eaa6@web.de> @ 2021-03-28 12:48 ` Julia Lawall 0 siblings, 0 replies; 16+ messages in thread From: Julia Lawall @ 2021-03-28 12:48 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1786 bytes --] On Sun, 28 Mar 2021, Markus Elfring wrote: > >> @display@ > >> @@ > >> *#define > > > > Obviously this doesn't work. Just like > > > > @@ > > @@ > > *if > > > > doesnt' work. > > Can it become possible to find such key words in the source code > (by such SmPL search approaches)? No. As has been explained many times before, Coccinelle works on complete terms - expressions, statements, etc. If you want to find keywords, use grep. julia > > > >> 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? > > The challenge to determine reasonable group criteria. > > > >> 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, > > Yes, of course. > > > > unless you want to provide all the values explicitly. > > Special identifier combinations can be converted to enumerations, can't they? > > > >>> 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 > > I got informed that some development tools can work better with enumeration identifiers > (instead of macro names). > > > > and the definitions are typically far from the uses. > > This is usual. > > Regards, > Markus > [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <b761969f-181b-5951-0730-11c340e236ab@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <b761969f-181b-5951-0730-11c340e236ab@web.de> @ 2021-03-28 14:08 ` Julia Lawall 0 siblings, 0 replies; 16+ messages in thread From: Julia Lawall @ 2021-03-28 14:08 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1086 bytes --] On Sun, 28 Mar 2021, Markus Elfring wrote: > >> 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? > > Can you help anyhow according to dealing with the longest common substring problem > in combination with discussed capabilities of the semantic patch language? You can implement whatever you want in python. > > > > 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. > > Some information from #define directives can be imported into symbol tables > for later transformations (on demand). > Source code positions need to be recorded accordingly, don't they? If you want to record the position of something you can use a position variable. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <f720b262-708f-a603-3470-b374db625578@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <f720b262-708f-a603-3470-b374db625578@web.de> @ 2021-03-28 14:45 ` Julia Lawall [not found] ` <fa66fce2-e60e-1907-7c8b-fd9ceedb8086@web.de> 0 siblings, 1 reply; 16+ messages in thread From: Julia Lawall @ 2021-03-28 14:45 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 2570 bytes --] On Sun, 28 Mar 2021, Markus Elfring wrote: > > And what is the problem here? > > Would you like to discuss further software development ideas > according to another SmPL script example like the following? The following looks like what one might want to do to find #defines that are near each other. julia > > > @initialize:python@ > @@ > import sys > > records = {} > > class integrity_error: > pass > > def store_positions(places, name, text): > """Add source code positions to an internal table.""" > for place in places: > key = place.file, place.line, int(place.column) + 1 > > if key in records: > sys.stderr.write("\n".join(["-> duplicate data", > "file:", key[0], > "function:", place.current_element, > "line:", str(place.line)])) > sys.stderr.write("\n") > raise integrity_error > else: > records[key] = name, text, place.current_element > > @find@ > expression e; > identifier i; > position p; > @@ > #define i@p e > > @script:python collection@ > i << find.i; > e << find.e; > places << find.p; > @@ > store_positions(places, i, e) > > @finalize:python@ > @@ > if len(records) > 0: > delimiter = "|" > sys.stdout.write(delimiter.join(['name', > 'text', > 'function', > '"source file"', > 'line', > 'column' > ])) > sys.stdout.write("\r\n") > > for key, value in records.items(): > sys.stdout.write(delimiter.join([value[0], > value[1], > value[2], > key[0], > key[1], > str(key[2]) > ])) > sys.stdout.write("\r\n") > else: > sys.stderr.write("No result for this analysis!\n") > > > elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch list_macros.cocci /usr/include/pipewire-0.3/pipewire/client.h > … > name|text|function|"source file"|line|column > … > PW_CLIENT_METHOD_GET_PERMISSIONS|3|something_else|/usr/include/pipewire-0.3/pipewire/client.h|98|1 > PW_CLIENT_METHOD_UPDATE_PROPERTIES|2|something_else|/usr/include/pipewire-0.3/pipewire/client.h|97|1 > … > > > Regards, > Markus > [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <fa66fce2-e60e-1907-7c8b-fd9ceedb8086@web.de>]
* Re: [Cocci] Excluding quotes from strings of #define directives [not found] ` <fa66fce2-e60e-1907-7c8b-fd9ceedb8086@web.de> @ 2021-04-04 11:58 ` Julia Lawall 2021-04-04 12:11 ` Markus Elfring 0 siblings, 1 reply; 16+ messages in thread From: Julia Lawall @ 2021-04-04 11:58 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 3484 bytes --] On Sun, 4 Apr 2021, Markus Elfring wrote: > > The following looks like what one might want to do to find #defines that > > are near each other. > > I have tried another SmPL script variant out. > > > @initialize:python@ > @@ > import sys > > records = {} > > class integrity_error: > pass > > def store_positions(places, name, text): > """Add source code positions to an internal table.""" > for place in places: > key = place.file, place.line, int(place.column) + 1 > > if key in records: > sys.stderr.write("\n".join(["-> duplicate data", > "file:", key[0], > "function:", place.current_element, > "line:", str(place.line)])) > sys.stderr.write("\n") > raise integrity_error > else: > records[key] = name, text, place.current_element > > @find@ > identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; > expression e !~ "\""; > position p; > @@ > #define i@p e > > @script:python collection@ > i << find.i; > e << find.e; > places << find.p; > @@ > store_positions(places, i, e) > > @finalize:python@ > @@ > if len(records) > 0: > delimiter = "|" > sys.stdout.write(delimiter.join(['name', > 'text', > 'function', > '"source file"', > 'line', > 'column' > ])) > sys.stdout.write("\r\n") > > for key, value in records.items(): > sys.stdout.write(delimiter.join([value[0], > value[1], > value[2], > key[0], > key[1], > str(key[2]) > ])) > sys.stdout.write("\r\n") > else: > sys.stderr.write("No result for this analysis!\n") > > > I wonder about the following test result then. > > elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/check_define_usage.cocci spa/include/spa/node/type-info.h > … > name|text|function|"source file"|line|column > SPA_TYPE_INFO_NodeCommand|SPA_TYPE_INFO_COMMAND_BASE "Node"|something_else|spa/include/spa/node/type-info.h|70|1 > SPA_TYPE_INFO_IO_BASE|SPA_TYPE_INFO_IO ":"|something_else|spa/include/spa/node/type-info.h|39|1 > SPA_TYPE_INFO_NODE_EVENT_BASE|SPA_TYPE_INFO_NodeEvent ":"|something_else|spa/include/spa/node/type-info.h|56|1 > SPA_TYPE_INFO_NodeEvent|SPA_TYPE_INFO_EVENT_BASE "Node"|something_else|spa/include/spa/node/type-info.h|55|1 > SPA_TYPE_INFO_IO|SPA_TYPE_INFO_ENUM_BASE "IO"|something_else|spa/include/spa/node/type-info.h|38|1 > SPA_TYPE_INFO_NODE_COMMAND_BASE|SPA_TYPE_INFO_NodeCommand ":"|something_else|spa/include/spa/node/type-info.h|71|1 > > > I hoped that the specified constraint for the metavariable “e” would mean > that expressions which contain a double quotation character should be excluded > for my source code analysis approach. > Would you like to check the observed software functionality once more? There is perhaps a problem, but it is surely not necessary to have all of this python code around it to see the problem. Please make a minimal example. A rule with a match and a * in front of it should be sufficient. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Excluding quotes from strings of #define directives 2021-04-04 11:58 ` [Cocci] Excluding quotes from strings of #define directives Julia Lawall @ 2021-04-04 12:11 ` Markus Elfring 2021-04-04 12:19 ` Julia Lawall 0 siblings, 1 reply; 16+ messages in thread From: Markus Elfring @ 2021-04-04 12:11 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> I hoped that the specified constraint for the metavariable “e” would mean >> that expressions which contain a double quotation character should be excluded >> for my source code analysis approach. >> Would you like to check the observed software functionality once more? > > There is perhaps a problem, but it is surely not necessary to have all of > this python code around it to see the problem. I chose this test display so that it can be clearly seen which data were processes for the metavariable “e”. > Please make a minimal example. A rule with a match and a * in front of it should be sufficient. Do you find constraints of the following SmPL script variant easier to clarify? @display@ identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; expression e !~ "\""; @@ *#define i e Test result: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/97b01ed9b01bac7cba68ff11c6bf7ceabcae7f52/spa/include/spa/node/type-info.h#L38 elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/show_define_usage4.cocci spa/include/spa/node/type-info.h … @@ -35,8 +35,6 @@ extern "C" { #include <spa/node/event.h> #include <spa/node/io.h> -#define SPA_TYPE_INFO_IO SPA_TYPE_INFO_ENUM_BASE "IO" -#define SPA_TYPE_INFO_IO_BASE SPA_TYPE_INFO_IO ":" static const struct spa_type_info spa_type_io[] = { { SPA_IO_Invalid, SPA_TYPE_Int, SPA_TYPE_INFO_IO_BASE "Invalid", NULL }, … Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Excluding quotes from strings of #define directives 2021-04-04 12:11 ` Markus Elfring @ 2021-04-04 12:19 ` Julia Lawall [not found] ` <b9f6aceb-7e68-303d-bd1e-d41a7992b58b@web.de> 0 siblings, 1 reply; 16+ messages in thread From: Julia Lawall @ 2021-04-04 12:19 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1596 bytes --] On Sun, 4 Apr 2021, Markus Elfring wrote: > >> I hoped that the specified constraint for the metavariable “e” would mean > >> that expressions which contain a double quotation character should be excluded > >> for my source code analysis approach. > >> Would you like to check the observed software functionality once more? > > > > There is perhaps a problem, but it is surely not necessary to have all of > > this python code around it to see the problem. > > I chose this test display so that it can be clearly seen which data were processes > for the metavariable “e”. > > > > Please make a minimal example. A rule with a match and a * in front of it should be sufficient. > > Do you find constraints of the following SmPL script variant easier to clarify? > > @display@ > identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; > expression e !~ "\""; > @@ > *#define i e > > Test result: > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/97b01ed9b01bac7cba68ff11c6bf7ceabcae7f52/spa/include/spa/node/type-info.h#L38 > > elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/show_define_usage4.cocci spa/include/spa/node/type-info.h > … > @@ -35,8 +35,6 @@ extern "C" { > #include <spa/node/event.h> > #include <spa/node/io.h> > > -#define SPA_TYPE_INFO_IO SPA_TYPE_INFO_ENUM_BASE "IO" > -#define SPA_TYPE_INFO_IO_BASE SPA_TYPE_INFO_IO ":" > > static const struct spa_type_info spa_type_io[] = { > { SPA_IO_Invalid, SPA_TYPE_Int, SPA_TYPE_INFO_IO_BASE "Invalid", NULL }, > … Thanks for the simpler examples. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <b9f6aceb-7e68-303d-bd1e-d41a7992b58b@web.de>]
* Re: [Cocci] Checking support for compound expressions (according to #define directives) [not found] ` <b9f6aceb-7e68-303d-bd1e-d41a7992b58b@web.de> @ 2021-04-05 7:09 ` Julia Lawall [not found] ` <8561006e-7dc6-0f62-ecf0-c93146976925@web.de> 0 siblings, 1 reply; 16+ messages in thread From: Julia Lawall @ 2021-04-05 7:09 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 726 bytes --] On Mon, 5 Apr 2021, Markus Elfring wrote: > > Thanks for the simpler examples. > > Would you like to support another search pattern by the means of > the semantic patch language? > > > @display@ > identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+", x; > constant c =~ "\""; > @@ > *#define i x c > > > elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_define_usage6.cocci > … > minus: parse error: > File "show_define_usage6.cocci", line 5, column 13, charpos = 92 > around = 'c', > whole content = *#define i x c No. You have to match the expression and then check it using python. YOu can write: @@ identifier i; expression e : script:python() { ... python code to ceck e }; @@ #define i e julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <8561006e-7dc6-0f62-ecf0-c93146976925@web.de>]
* Re: [Cocci] Checking support for compound expressions (according to #define directives) [not found] ` <8561006e-7dc6-0f62-ecf0-c93146976925@web.de> @ 2021-04-05 7:54 ` Julia Lawall 2021-04-05 8:46 ` Markus Elfring 2021-04-05 10:37 ` [Cocci] Improve the handling of string literals with SmPL Markus Elfring 0 siblings, 2 replies; 16+ messages in thread From: Julia Lawall @ 2021-04-05 7:54 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 860 bytes --] On Mon, 5 Apr 2021, Markus Elfring wrote: > >> @display@ > >> identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+", x; > >> constant c =~ "\""; > >> @@ > >> *#define i x c > >> > >> > >> elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_define_usage6.cocci > >> … > >> minus: parse error: > >> File "show_define_usage6.cocci", line 5, column 13, charpos = 92 > >> around = 'c', > >> whole content = *#define i x c > > > > No. You have to match the expression and then check it using python. > > I find this view improvable. > > I would like to avoid the repetition of parsing efforts as much as possible. > Under which circumstances can replacement lists be taken better into account? Why does my suggestion involve a repetition of parsing effort? You want to use a regexp. I'm asking you to put the regexp in a python function. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Checking support for compound expressions (according to #define directives) 2021-04-05 7:54 ` Julia Lawall @ 2021-04-05 8:46 ` Markus Elfring 2021-04-05 8:53 ` Julia Lawall 2021-04-05 10:37 ` [Cocci] Improve the handling of string literals with SmPL Markus Elfring 1 sibling, 1 reply; 16+ messages in thread From: Markus Elfring @ 2021-04-05 8:46 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle >> I would like to avoid the repetition of parsing efforts as much as possible. >> Under which circumstances can replacement lists be taken better into account? > > Why does my suggestion involve a repetition of parsing effort? The selection of the applied programming interfaces has got significant influences on the run time behaviour. See also: https://github.com/coccinelle/coccinelle/issues/200#issuecomment-653775288 > You want to use a regexp. This view depends on some factors. I would prefer to search for string literals (and their exclusion) by higher level means. > I'm asking you to put the regexp in a python function. How do you think about to improve the following software situation besides the application of regular expressions? @initialize:python@ @@ import re @display@ identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; expression e : script:python() { re.match('"', e) }; @@ *#define i e elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/show_define_usage7.cocci spa/include/spa/node/type-info.h … File "<string>", line 5 coccinelle.result = (re . match ( " , e )) ^ SyntaxError: EOL while scanning string literal Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Checking support for compound expressions (according to #define directives) 2021-04-05 8:46 ` Markus Elfring @ 2021-04-05 8:53 ` Julia Lawall 0 siblings, 0 replies; 16+ messages in thread From: Julia Lawall @ 2021-04-05 8:53 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1393 bytes --] On Mon, 5 Apr 2021, Markus Elfring wrote: > >> I would like to avoid the repetition of parsing efforts as much as possible. > >> Under which circumstances can replacement lists be taken better into account? > > > > Why does my suggestion involve a repetition of parsing effort? > > The selection of the applied programming interfaces has got significant influences > on the run time behaviour. > > See also: > https://github.com/coccinelle/coccinelle/issues/200#issuecomment-653775288 > > > > You want to use a regexp. > > This view depends on some factors. > I would prefer to search for string literals (and their exclusion) by higher level means. > > > > I'm asking you to put the regexp in a python function. > > How do you think about to improve the following software situation > besides the application of regular expressions? > > @initialize:python@ > @@ > import re > > @display@ > identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; > expression e : script:python() { re.match('"', e) }; > @@ > *#define i e > > > elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/show_define_usage7.cocci spa/include/spa/node/type-info.h > … > File "<string>", line 5 > coccinelle.result = (re . match ( " , e )) > ^ > SyntaxError: EOL while scanning string literal This looks like a problem. Thanks for the report. julia [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Cocci] Improve the handling of string literals with SmPL 2021-04-05 7:54 ` Julia Lawall 2021-04-05 8:46 ` Markus Elfring @ 2021-04-05 10:37 ` Markus Elfring 1 sibling, 0 replies; 16+ messages in thread From: Markus Elfring @ 2021-04-05 10:37 UTC (permalink / raw) To: Julia Lawall; +Cc: Coccinelle > I'm asking you to put the regexp in a python function. Will it become easier and more convenient to search for string literals (and their exclusion according to the discussed transformation approach)? @initialize:python@ @@ def occurs(x): return '"' in x @display@ identifier i =~ "^(?:[A-Z]+_){3,3}[A-Z]+"; expression e : script:python() { occurs(e) }; @@ *#define i e elfring@Sonne:~/Projekte/PipeWire/lokal> spatch ~/Projekte/Coccinelle/janitor/show_define_usage8.cocci spa/include/spa/node/type-info.h … @@ -35,8 +35,6 @@ extern "C" { #include <spa/node/event.h> #include <spa/node/io.h> -#define SPA_TYPE_INFO_IO SPA_TYPE_INFO_ENUM_BASE "IO" -#define SPA_TYPE_INFO_IO_BASE SPA_TYPE_INFO_IO ":" static const struct spa_type_info spa_type_io[] = { { SPA_IO_Invalid, SPA_TYPE_Int, SPA_TYPE_INFO_IO_BASE "Invalid", NULL }, … How will the software design clarification evolve further? Regards, Markus _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
[parent not found: <eaa316bd-4c73-fcbb-bfad-20426348b1c2@web.de>]
* Re: [Cocci] Replacing #define directives with the help of SmPL [not found] ` <eaa316bd-4c73-fcbb-bfad-20426348b1c2@web.de> @ 2021-03-28 15:17 ` Julia Lawall 0 siblings, 0 replies; 16+ messages in thread From: Julia Lawall @ 2021-03-28 15:17 UTC (permalink / raw) To: Markus Elfring; +Cc: Coccinelle [-- Attachment #1: Type: text/plain, Size: 1247 bytes --] On Sun, 28 Mar 2021, Markus Elfring wrote: > >> Would you like to help any more with attempts to achieve support for > >> a transformation pattern like “#define ⇒ enum” according to the semantic patch language? > >> https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/981 > >> https://github.com/issues?q=is%3Aissue+author%3Aelfring+%22+enum%22 > > > > If you find that something does not work satisfactorily, propose a > > semantic patch and show what doesn't work. I'm not going to try to solve > > a problem when I don't know what the problem is. > > Please take another look at the following SmPL script variant. > > > @display3@ > expression e; > identifier i, s; > @@ > struct s { > ... > *#define i e > ... > }; > > > elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch --parse-cocci show_define_usage3.cocci > init_defs_builtins: /usr/local/bin/../lib/coccinelle/standard.h > minus: parse error: > File "show_define_usage3.cocci", line 7, column 1, charpos = 63 > around = '#define i', > whole content = *#define i e This is not supported. julia > > > See also: > https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/2681b8236b332abdaf707ab8c5017a9be92d1059/src/pipewire/client.h#L46 > > Regards, > Markus > [-- Attachment #2: Type: text/plain, Size: 136 bytes --] _______________________________________________ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2021-04-08 15:44 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-28 7:19 [Cocci] Replacing #define directives with the help of SmPL Markus Elfring
2021-03-28 9:29 ` Julia Lawall
[not found] ` <1b5f6d22-5b89-097f-37bd-13b3b2ab011a@web.de>
2021-03-28 10:47 ` Julia Lawall
[not found] ` <173fa182-4127-aaba-262e-e3953a81a1e2@web.de>
2021-03-28 11:46 ` Julia Lawall
[not found] ` <b80fe77f-0a11-2000-522e-836c9368eaa6@web.de>
2021-03-28 12:48 ` Julia Lawall
[not found] ` <b761969f-181b-5951-0730-11c340e236ab@web.de>
2021-03-28 14:08 ` Julia Lawall
[not found] ` <f720b262-708f-a603-3470-b374db625578@web.de>
2021-03-28 14:45 ` Julia Lawall
[not found] ` <fa66fce2-e60e-1907-7c8b-fd9ceedb8086@web.de>
2021-04-04 11:58 ` [Cocci] Excluding quotes from strings of #define directives Julia Lawall
2021-04-04 12:11 ` Markus Elfring
2021-04-04 12:19 ` Julia Lawall
[not found] ` <b9f6aceb-7e68-303d-bd1e-d41a7992b58b@web.de>
2021-04-05 7:09 ` [Cocci] Checking support for compound expressions (according to #define directives) Julia Lawall
[not found] ` <8561006e-7dc6-0f62-ecf0-c93146976925@web.de>
2021-04-05 7:54 ` Julia Lawall
2021-04-05 8:46 ` Markus Elfring
2021-04-05 8:53 ` Julia Lawall
2021-04-05 10:37 ` [Cocci] Improve the handling of string literals with SmPL Markus Elfring
[not found] ` <eaa316bd-4c73-fcbb-bfad-20426348b1c2@web.de>
2021-03-28 15:17 ` [Cocci] Replacing #define directives with the help of SmPL Julia Lawall
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.