Re: [Cocci] Function-like macro with the same name as a typedef
Markus Elfring writes: >>> * How many software implementations use identical type definitions >>> and function-like macros? >> >> I don't know. > > Can it become interesting to find more about such usage patterns out? Rule of thumb: for every user reporting an issue, there are several more suffering quietly. How many more? I don't know. A better estimate of how widespread such use is might be useful, but I can't provide one. >> For what it's worth, it's valid C. Unless I'm mistaken, >> Coccinelle tries to support as much of C as it possibly can. > > How do you think about limitations for corresponding software > development resources? > > >> The QEMU project can certainly work around this Coccinelle >> bug / restriction. > > Which adjustments will be chosen? Rename either the typedef or the macro. More complicated than it sounds, because both conform to naming conventions. >>> * How will the evolution be continued around Coccinelle? >> >> Is this a question about Coccinelle's future? > > Yes, of course. > > Are we trying to influence further development anyhow? I'm trying to help the Coccinelle project by reporting an issue, no more, no less :) ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Function-like macro with the same name as a typedef
Markus Elfring writes: * spatch seems to have trouble parsing ARMSSE *s = ARMSSE(opaque); where ARMSSE is a typedef, and ARMSSE() is a function-like macro. Yes, I know that's in rather poor taste. >>> >>> I am curious for the safe handling of related software development >>> challenges. >>> >>> * Workaround #1: rename the typedef to ARMSSE_ >>> >>> Will adjustments become more interesting also around such name space issues? >> >> I'm not sure I understand your question. Can you elaborate? > > Do we come along the need to adjust (or even improve) two software areas? > > * How many software implementations use identical type definitions > and function-like macros? I don't know. For what it's worth, it's valid C. Unless I'm mistaken, Coccinelle tries to support as much of C as it possibly can. The QEMU project can certainly work around this Coccinelle bug / restriction. I'm reporting it because I've found Coccinelle useful. > * How will the evolution be continued around Coccinelle? Is this a question about Coccinelle's future? ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] [PATCH net-next v1] can: ti_hecc: convert to devm_platform_ioremap_resource_byname()
On Sun, Apr 19, 2020 at 06:19:12PM +0200, Markus Elfring wrote: > > use devm_platform_ioremap_resource_byname() to simplify code, > > it contains platform_get_resource_byname() and > > devm_ioremap_resource(), and also remove some duplicate error > > message. > > How do you think about a wording variant like the following? > >Use the function “devm_platform_ioremap_resource_byname” to simplify >source code which calls the functions “platform_get_resource_byname” >and “devm_ioremap_resource”. >Remove also a few error messages which became unnecessary with this >software refactoring. > Markus, Thank you very much！yes, your comments is better. I will send the patch v2. Thanks again! > > Will any more contributors get into the development mood to achieve > similar collateral evolution by the means of the semantic patch language? > Would you like to increase applications of the Coccinelle software? > I want, but currently I don't have much free time, sorry！ BR, Dejin > Regards, > Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Function-like macro with the same name as a typedef
Markus Elfring writes: >> * spatch seems to have trouble parsing >> >> ARMSSE *s = ARMSSE(opaque); >> >> where ARMSSE is a typedef, and ARMSSE() is a function-like macro. >> Yes, I know that's in rather poor taste. > > I am curious for the safe handling of related software development challenges. > > >> * Workaround #1: rename the typedef to ARMSSE_ > > Will adjustments become more interesting also around such name space issues? I'm not sure I understand your question. Can you elaborate? ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Function-like macro with the same name as a typedef
>> * How many software implementations use identical type definitions >> and function-like macros? > > I don't know. Can it become interesting to find more about such usage patterns out? > For what it's worth, it's valid C. Unless I'm mistaken, > Coccinelle tries to support as much of C as it possibly can. How do you think about limitations for corresponding software development resources? > The QEMU project can certainly work around this Coccinelle > bug / restriction. Which adjustments will be chosen? >> * How will the evolution be continued around Coccinelle? > > Is this a question about Coccinelle's future? Yes, of course. Are we trying to influence further development anyhow? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Function-like macro with the same name as a typedef
>>> * spatch seems to have trouble parsing >>> >>> ARMSSE *s = ARMSSE(opaque); >>> >>> where ARMSSE is a typedef, and ARMSSE() is a function-like macro. >>> Yes, I know that's in rather poor taste. >> >> I am curious for the safe handling of related software development >> challenges. >> >> >>> * Workaround #1: rename the typedef to ARMSSE_ >> >> Will adjustments become more interesting also around such name space issues? > > I'm not sure I understand your question. Can you elaborate? Do we come along the need to adjust (or even improve) two software areas? * How many software implementations use identical type definitions and function-like macros? * How will the evolution be continued around Coccinelle? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] Checking the replacement of two specific function calls
> Another possibility should be taken into account for source code variations. > > SmPL script example: > @replacement@ > expression base, device1, device2, index, private; > @@ > -private->res = platform_get_resource(device1, IORESOURCE_MEM, index); > base = > - devm_ioremap_resource > + devm_platform_get_and_ioremap_resource > (device2, > + index, & > private->res > ); Such a transformation approach can work to some degree. Thus I would expect that it can be reused for a case distinction in the way of a SmPL disjunction like the following. Another SmPL script example: @replacement@ expression base, device1, device2, index, private, resource; @@ -resource = platform_get_resource(device1, IORESOURCE_MEM, index); base = - devm_ioremap_resource + devm_platform_get_and_ioremap_resource ( ( - & device1 - ->dev , + index, & resource | device2, + index, & private->res ) ); Test command: elfring@Sonne:~/Projekte/Coccinelle/janitor> spatch use_devm_platform_get_and_ioremap_resource10.cocci ../Probe/i2c-rcar-excerpt-20200415.c Now I wonder again why the known patch is not generated as expected so far. How would you like to clarify this software situation? Regards, Markus ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
