On Thu, Oct 19, 2017 at 04:58:23PM +, alexander.stef...@infineon.com wrote:
> > On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer dereferences
> > > > > as the parameter for the operator "sizeof"
> On Fri, Oct 20, 2017 at 12:01:39PM +0300, Jarkko Sakkinen wrote:
> > On Thu, Oct 19, 2017 at 04:58:23PM +,
> alexander.stef...@infineon.com wrote:
> > > > On Tue, Oct 17, 2017 at 11:50:05AM +,
> alexander.stef...@infineon.com
> > > > wrote:
> > > > > > > Replace the specification of data
On Fri, Oct 20, 2017 at 12:01:39PM +0300, Jarkko Sakkinen wrote:
> On Thu, Oct 19, 2017 at 04:58:23PM +, alexander.stef...@infineon.com
> wrote:
> > > On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com
> > > wrote:
> > > > > > Replace the specification of data structures
On Thu, Oct 19, 2017 at 04:58:23PM +, alexander.stef...@infineon.com wrote:
> > On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer dereferences
> > > > > as the parameter for the operator "sizeof"
> On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer dereferences
> > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > size
> > > > determination a bit safer according to t
On Wed, Oct 18, 2017 at 07:48:06PM +0200, SF Markus Elfring wrote:
> > For 1/4 and 2/4: explain why the message can be omitted.
>
> Why did you not reply directly with this request for the update steps
> with the subject “Delete an error message for a failed memory allocation
> in tpm_…()”?
>
> h
On Wed, 18 Oct 2017 21:03:13 +0300
Andy Shevchenko wrote:
> On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote:
> > > For 1/4 and 2/4: explain why the message can be omitted.
>
> > > That's all.
> >
> > I assume that there might be also some communication challenges
> > involved.
>
On Wed Oct 18 17, SF Markus Elfring wrote:
For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/100
On Wed, 2017-10-18 at 19:48 +0200, SF Markus Elfring wrote:
> > For 1/4 and 2/4: explain why the message can be omitted.
> > That's all.
>
> I assume that there might be also some communication challenges
> involved.
>
>
> > 3/4: definitive NAK, too much noise compared to value.
>
> I tried to
> One more word of advice: send the three as separate patches.
I do not see a need for an immediate resend at the moment.
> My guess is that it takes a factor longer time to apply 4/4
> than other patches because there's more limited crowd who can test it.
This is fine for me if somebody would
> For 1/4 and 2/4: explain why the message can be omitted.
Why did you not reply directly with this request for the update steps
with the subject “Delete an error message for a failed memory allocation
in tpm_…()”?
https://patchwork.kernel.org/patch/10009405/
https://patchwork.kernel.org/patch/10
On Wed, Oct 18, 2017 at 08:18:58PM +0300, Jarkko Sakkinen wrote:
> On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > > Commit message should just describe in plain text what you are doing
> >
> > Did other contributors find the wording “Replace …”
> >
> >
> > > and why.
> >
On Wed, Oct 18, 2017 at 06:43:10PM +0200, SF Markus Elfring wrote:
> > Commit message should just describe in plain text what you are doing
>
> Did other contributors find the wording “Replace …”
>
>
> > and why.
>
> and “… a bit safer according to the Linux coding style convention.”
> sufficie
> Commit message should just describe in plain text what you are doing
Did other contributors find the wording “Replace …”
> and why.
and “… a bit safer according to the Linux coding style convention.”
sufficient often enough already?
Which description would you find more appropriate for this
On Wed, Oct 18, 2017 at 05:22:19PM +0200, SF Markus Elfring wrote:
> >> Do you find my wording “This issue was detected by using the
> >> Coccinelle software.” insufficient?
> >
> > This is fine for cover letter, not for the commits.
>
> I guess that there are more opinions available by other con
>> Do you find my wording “This issue was detected by using the
>> Coccinelle software.” insufficient?
>
> This is fine for cover letter, not for the commits.
I guess that there are more opinions available by other contributors
for this aspect.
> After your analysis software finds an issue you
On Tue, Oct 17, 2017 at 08:41:04PM +0200, SF Markus Elfring wrote:
> Do you find my wording “This issue was detected by using the
> Coccinelle software.” insufficient?
This is fine for cover letter, not for the commits.
After your analysis software finds an issue you should manually analyze
what
On Tue, Oct 17, 2017 at 04:02:05PM +0300, Andy Shevchenko wrote:
> On Tue, 2017-10-17 at 08:52 -0400, Mimi Zohar wrote:
> > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer
> > > > > dereferences
> > > > >
On Tue, Oct 17, 2017 at 11:50:05AM +, alexander.stef...@infineon.com wrote:
> > > Replace the specification of data structures by pointer dereferences
> > > as the parameter for the operator "sizeof" to make the corresponding
> > > size
> > > determination a bit safer according to the Linux cod
On Tue, Oct 17, 2017 at 02:03:02PM +0300, Andy Shevchenko wrote:
> On Mon, 2017-10-16 at 19:33 +0200, SF Markus Elfring wrote:
> > From: Markus Elfring
> > Date: Mon, 16 Oct 2017 18:28:17 +0200
> >
> > Replace the specification of data structures by pointer dereferences
> > as the parameter for t
> On Tue, 17 Oct 2017, Mimi Zohar wrote:
>
> > On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote:
> > >
> > > On Tue, 17 Oct 2017, Mimi Zohar wrote:
> > >
> > > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > > > wrote:
> > > > > > > Replace the specification of data st
> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer dereferences
> > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > size
> > > > determination a bit safer according to the Linu
> > Replace the specification of data structures by pointer dereferences
> > as the parameter for the operator "sizeof" to make the corresponding
> > size
> > determination a bit safer according to the Linux coding style
> > convention.
>
>
> This patch does one style in favor of the other.
I ac
>> I imagine that a corresponding source code analysis variant could be applied
>> in more cases if sufficient acceptance could be achieved.
>
> So, then instead of still keeping people busy with this noise you better
> start doing something like CI integration with that for *new* code?
There are
>> Do you find my wording “This issue was detected by using the
>> Coccinelle software.” insufficient?
>
> The question is not whether it is insufficient, but whether it is appropriate.
I am curious on how our corresponding discussion will evolve further.
> Detecting Coccinelle issues is one st
On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote:
> > > p = kmalloc(sizeof(*p), ...);
> > >
> > > The alternative form where struct name is spelled out hurts
> > > readability and
> > > introduces an opportunity for a bug when the pointer variable type
> > > is changed
> > > but the co
On Tue, 2017-10-17 at 20:41 +0200, SF Markus Elfring wrote:
> Do you find my wording “This issue was detected by using the
> Coccinelle software.” insufficient?
The question is not whether it is insufficient, but whether it is
appropriate. Detecting Coccinelle issues is one step. The next step
>> p = kmalloc(sizeof(*p), ...);
>>
>> The alternative form where struct name is spelled out hurts readability and
>> introduces an opportunity for a bug when the pointer variable type is changed
>> but the corresponding sizeof that is passed to a memory allocator is not.
>
> True, thanks for
On Tue, 17 Oct 2017, Mimi Zohar wrote:
> On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote:
> >
> > On Tue, 17 Oct 2017, Mimi Zohar wrote:
> >
> > > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > > wrote:
> > > > > > Replace the specification of data structures by poin
On Tue, 2017-10-17 at 14:58 +0200, Julia Lawall wrote:
>
> On Tue, 17 Oct 2017, Mimi Zohar wrote:
>
> > On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> > wrote:
> > > > > Replace the specification of data structures by pointer dereferences
> > > > > as the parameter for the op
On Tue, 2017-10-17 at 08:52 -0400, Mimi Zohar wrote:
> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer
> > > > dereferences
> > > > as the parameter for the operator "sizeof" to make the
> > > > corresponding
On Tue, 17 Oct 2017, Mimi Zohar wrote:
> On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
> wrote:
> > > > Replace the specification of data structures by pointer dereferences
> > > > as the parameter for the operator "sizeof" to make the corresponding
> > > > size
> > > > deter
On Tue, 2017-10-17 at 11:50 +, alexander.stef...@infineon.com
wrote:
> > > Replace the specification of data structures by pointer dereferences
> > > as the parameter for the operator "sizeof" to make the corresponding
> > > size
> > > determination a bit safer according to the Linux coding sty
On Mon, 2017-10-16 at 19:33 +0200, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 16 Oct 2017 18:28:17 +0200
>
> Replace the specification of data structures by pointer dereferences
> as the parameter for the operator "sizeof" to make the corresponding
> size
> determination a bit s
From: Markus Elfring
Date: Mon, 16 Oct 2017 18:28:17 +0200
Replace the specification of data structures by pointer dereferences
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.
This issue was detec
35 matches
Mail list logo