On Thu, 23 Jul 2015, SF Markus Elfring wrote:
> > You can use arguments like --show-trying and --debug to see
> > where it is getting stuck, if that is the case.
>
> How do you think about to try another analysis out with one
> of your test systems?
I don't have your semantic patch. If you want me to to try something, you
have to send the semantic patch, even if you have sent it before.
But have you looked at the result of --show-trying and looked at the last
function that it prints to see why that function might be time consuming?
> "source file"|duration|comment|function
> udev-rules.c|234.2|EXN:Common.Timeout|add_rule
> udev-builtin-usb_id.c|234.4|EXN:Common.Timeout|builtin_usb_id
> udev-builtin-net_id.c|13.0||
> udev-builtin-input_id.c|45.1||
> udevadm-monitor.c|168.5||
> udevadm-control.c|240.0|EXN:Common.Timeout|adm_control
> collect/collect.c|27.1||
> cdrom_id/cdrom_id.c|234.4|EXN:Common.Timeout|main
> ata_id/ata_id.c|252.5|EXN:Common.Timeout|main
>
>
> I extended the corresponding SmPL script also with the
> following specifications.
>
> @show_unstored_return_values@
> binary operator bo;
> expression express;
> …
> statement es, is;
> …
> |
> if (allocation(...) bo express) is else es;
There should not be a semicolon after es. Since es is a statement, the
semicolon represents an empty statement, which your code is unlikely to
contain.
julia
_______________________________________________
Cocci mailing list
[email protected]
https://systeme.lip6.fr/mailman/listinfo/cocci
