On Sun, Nov 23, 2014 at 02:24:32PM +0100, SF Markus Elfring wrote:
> > Program analysis tools can also potentially exploit this information,
>
> The published semantic patch scripts correspond to this desire.
>
Sorry for that.
I have deleted the Smatch check for this so it no longer warns about
> Normally, tests only hurt readability if they cannot be false or cannot be
> true.
> Making a choice apparent when there really is a choice would seem
> to aid understanding.
I agree also to such facts.
> Program analysis tools can also potentially exploit this information,
The published s
> > No, it's not. You should just try to write the most readable software
> > you can instead of removing if statements because you can.
>
> Additional safety checks have also got an effect on source code readability,
> haven't they?
Normally, tests only hurt readability if they cannot be false
On Mon, Nov 17, 2014 at 09:56:22AM +0100, SF Markus Elfring wrote:
> > You removed the statement from "if (foo) kfree_fsm(foo);" so now it
> > prints a warning.
> >
> > drivers/s390/net/fsm.c
>
> Would it be better to continue the clarification of affected implementation
> details
> under the di
> You removed the statement from "if (foo) kfree_fsm(foo);" so now it
> prints a warning.
>
> drivers/s390/net/fsm.c
Would it be better to continue the clarification of affected implementation
details
under the discussion topic "s390/net: Deletion of unnecessary checks before two
function calls
On Sun, Nov 16, 2014 at 12:48:37PM +0100, SF Markus Elfring wrote:
> > An example of a bug introduced is here:
> >
> > https://lkml.org/lkml/2014/11/3/505
>
> It seems that we try to clarify a different interpretation of "bugs", don't
> we?
>
You removed the statement from "if (foo) kfree_fsm(
> The original code is very clear, the new code works exactly the same but
> it's not clear if the author forgot about handling errors from
> audit_log_start().
We have got different expectations on source code clarity here.
> So now someone will come along later and add:
> if (!ab)
>
> An example of a bug introduced is here:
>
> https://lkml.org/lkml/2014/11/3/505
It seems that we try to clarify a different interpretation of "bugs", don't we?
It is an usual software development challenge to decide on the best source code
places
where to put input parameter validation (and w
On Sun, Nov 16, 2014 at 11:40:26AM +0100, SF Markus Elfring wrote:
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> index 21eae3c..1fed61c 100644
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -1470,8 +1470,7 @@ static void audit_log_exit(struct audit_context
> *context, struct task_st
On Sun, Nov 16, 2014 at 02:10:23PM +0300, Dan Carpenter wrote:
> Please don't send these to trivial, because they can introduce bugs.
An example of a bug introduced is here:
https://lkml.org/lkml/2014/11/3/505
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe l
Please don't send these to trivial, because they can introduce bugs.
The make the code less clear and they are a layering violation. If the
other maintainers want to take them that's fine, but don't send it to
trivial.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsu
From: Markus Elfring
Date: Sun, 16 Nov 2014 11:27:43 +0100
The audit_log_end() function tests whether its argument is NULL and then
returns immediately. Thus the test around the call is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring
---
ker
12 matches
Mail list logo
