On Fri, Aug 10, 2018 at 05:45:46PM +0300, Denis Efremov wrote:
> My mistake. Initially, I thought that this line signals about errors
> in the code, but now I see that this is about the tool's internal
> error. However, this doesn't change the fact that coccicheck returns
> the improper error code.
My mistake. Initially, I thought that this line signals about errors
in the code, but now I see that this is about the tool's internal
error. However, this doesn't change the fact that coccicheck returns
the improper error code.
I will reformulate the commit message and send the v2 patch with the
On Fri, 10 Aug 2018, Denis Efremov wrote:
> > Do you mean that there is an error in the behavior of coccicheck or that
> > coccicheck finds an error in the source code?
>
> An error in the source code.
>
> Here is an example of how the patch changes the behavior of 'make
> coccicheck' (my comm
> Do you mean that there is an error in the behavior of coccicheck or that
> coccicheck finds an error in the source code?
An error in the source code.
Here is an example of how the patch changes the behavior of 'make
coccicheck' (my comments after the ###):
Current behavior:
$ make M=mymodule c
On Fri, 10 Aug 2018, efre...@linux.com wrote:
> If coccicheck finds errors,
What do you mean by finds errors? Do you mean that there is an error in
the behavior of coccicheck or that coccicheck finds an error in the source
code?
To put it another way, can you give an example of the kind of e
If coccicheck finds errors, it should return an error code
distinct from zero. Current code instead of exiting with an
error code of coccinelle returns error code of
'echo "coccicheck failed"' which is almost always equals to zero,
thus failing original intention of alerting about errors.
This patc
6 matches
Mail list logo
