On Mon, 2017-11-27 at 12:58 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 11:57 AM, Joe Perches wrote:
> > It may or not be correct.
>
> It's absolutely not correct in that it either requires that a subsequent
> KERN_CONT/pr_cont or a '\n' at the end and it has neither.
The warning described
On Mon, 2017-11-27 at 12:58 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 11:57 AM, Joe Perches wrote:
> > It may or not be correct.
>
> It's absolutely not correct in that it either requires that a subsequent
> KERN_CONT/pr_cont or a '\n' at the end and it has neither.
The warning described
On 27/11/17 01:49 PM, Julia Lawall wrote:
Perhaps if there is a possible flow from one print to another within a
single function and in both cases the format string is at least say 25
characters (completely random value), then it is pretty likely that a
newline is intended.
This is on the
On 27/11/17 01:49 PM, Julia Lawall wrote:
Perhaps if there is a possible flow from one print to another within a
single function and in both cases the format string is at least say 25
characters (completely random value), then it is pretty likely that a
newline is intended.
This is on the
On Mon, 27 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 27/11/17 11:57 AM, Joe Perches wrote:
> > It may or not be correct.
>
> It's absolutely not correct in that it either requires that a subsequent
> KERN_CONT/pr_cont or a '\n' at the end and it has neither.
>
> > Without inter-function call
On Mon, 27 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 27/11/17 11:57 AM, Joe Perches wrote:
> > It may or not be correct.
>
> It's absolutely not correct in that it either requires that a subsequent
> KERN_CONT/pr_cont or a '\n' at the end and it has neither.
>
> > Without inter-function call
On 27/11/17 11:57 AM, Joe Perches wrote:
It may or not be correct.
It's absolutely not correct in that it either requires that a subsequent
KERN_CONT/pr_cont or a '\n' at the end and it has neither.
Without inter-function call code flow analysis,
it's not possible to be correct.
But
On 27/11/17 11:57 AM, Joe Perches wrote:
It may or not be correct.
It's absolutely not correct in that it either requires that a subsequent
KERN_CONT/pr_cont or a '\n' at the end and it has neither.
Without inter-function call code flow analysis,
it's not possible to be correct.
But
On Mon, 2017-11-27 at 10:44 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 10:42 AM, Joe Perches wrote:
> > No double stardard. One correctly informs that a bare
> > printk is not acceptable.
>
> The other correctly informs that a printk that isn't followed by a
> pr_cont or KERN_CONT is not
On Mon, 2017-11-27 at 10:44 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 10:42 AM, Joe Perches wrote:
> > No double stardard. One correctly informs that a bare
> > printk is not acceptable.
>
> The other correctly informs that a printk that isn't followed by a
> pr_cont or KERN_CONT is not
On 27/11/17 10:42 AM, Joe Perches wrote:
No double stardard. One correctly informs that a bare
printk is not acceptable.
The other correctly informs that a printk that isn't followed by a
pr_cont or KERN_CONT is not correct.
Logan
On 27/11/17 10:42 AM, Joe Perches wrote:
No double stardard. One correctly informs that a bare
printk is not acceptable.
The other correctly informs that a printk that isn't followed by a
pr_cont or KERN_CONT is not correct.
Logan
On 27/11/17 10:41 AM, Joe Perches wrote:
It can't be determined if the vaf.fmt contains a \n termination.
Yes, that's why we aren't warning. This could potentially be a false
negative which you haven't said is a problem up until now. If we have to
worry about false negatives too then your
On 27/11/17 10:41 AM, Joe Perches wrote:
It can't be determined if the vaf.fmt contains a \n termination.
Yes, that's why we aren't warning. This could potentially be a false
negative which you haven't said is a problem up until now. If we have to
worry about false negatives too then your
On Mon, 2017-11-27 at 10:35 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 10:28 AM, Joe Perches wrote:
> > It doesn't miss any mark. It simply informs.
> > Correctness when fixing are a different world of problems.
>
> So how come the double standard?
No double stardard. One correctly informs
On Mon, 2017-11-27 at 10:35 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 10:28 AM, Joe Perches wrote:
> > It doesn't miss any mark. It simply informs.
> > Correctness when fixing are a different world of problems.
>
> So how come the double standard?
No double stardard. One correctly informs
On Mon, 2017-11-27 at 10:33 -0700, Logan Gunthorpe wrote:
> > > This is a valid false positive that I also missed. However, it can
> > > actually be very easily ignored by checking if the format string ends in
> > > %pV. There were about 100 cases in my results that match this.
> >
> > No, it
On Mon, 2017-11-27 at 10:33 -0700, Logan Gunthorpe wrote:
> > > This is a valid false positive that I also missed. However, it can
> > > actually be very easily ignored by checking if the format string ends in
> > > %pV. There were about 100 cases in my results that match this.
> >
> > No, it
On 27/11/17 10:28 AM, Joe Perches wrote:
It doesn't miss any mark. It simply informs.
Correctness when fixing are a different world of problems.
So how come the double standard? Having a missing new line warning
simply informs here too. In fact, if you read my example, it informs in
On 27/11/17 10:28 AM, Joe Perches wrote:
It doesn't miss any mark. It simply informs.
Correctness when fixing are a different world of problems.
So how come the double standard? Having a missing new line warning
simply informs here too. In fact, if you read my example, it informs in
This is a valid false positive that I also missed. However, it can
actually be very easily ignored by checking if the format string ends in
%pV. There were about 100 cases in my results that match this.
No, it can't be done that way.
$ git grep '%pV\\n"' | wc -l
56
$ git grep '%pV"' | wc -l
This is a valid false positive that I also missed. However, it can
actually be very easily ignored by checking if the format string ends in
%pV. There were about 100 cases in my results that match this.
No, it can't be done that way.
$ git grep '%pV\\n"' | wc -l
56
$ git grep '%pV"' | wc -l
On Mon, 2017-11-27 at 10:20 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 01:28 AM, Joe Perches wrote:
> > checkpatch already reports printks without KERN_
> >
> > # printk should use KERN_* levels
> > if ($line =~ /\bprintk\s*\(\s*(?!KERN_[A-Z]+\b)/) {
> >
On Mon, 2017-11-27 at 10:20 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 01:28 AM, Joe Perches wrote:
> > checkpatch already reports printks without KERN_
> >
> > # printk should use KERN_* levels
> > if ($line =~ /\bprintk\s*\(\s*(?!KERN_[A-Z]+\b)/) {
> >
On Mon, 2017-11-27 at 10:07 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 02:25 AM, Joe Perches wrote:
> > []
> > diff -u -p a/lib/locking-selftest.c b/lib/locking-selftest.c
> > --- a/lib/locking-selftest.c
> > +++ b/lib/locking-selftest.c
> > @@ -1186,7 +1186,7 @@ static void dotest(void
On Mon, 2017-11-27 at 10:07 -0700, Logan Gunthorpe wrote:
>
> On 27/11/17 02:25 AM, Joe Perches wrote:
> > []
> > diff -u -p a/lib/locking-selftest.c b/lib/locking-selftest.c
> > --- a/lib/locking-selftest.c
> > +++ b/lib/locking-selftest.c
> > @@ -1186,7 +1186,7 @@ static void dotest(void
On 27/11/17 01:28 AM, Joe Perches wrote:
checkpatch already reports printks without KERN_
# printk should use KERN_* levels
if ($line =~ /\bprintk\s*\(\s*(?!KERN_[A-Z]+\b)/) {
WARN("PRINTK_WITHOUT_KERN_LEVEL",
"printk()
On 27/11/17 01:28 AM, Joe Perches wrote:
checkpatch already reports printks without KERN_
# printk should use KERN_* levels
if ($line =~ /\bprintk\s*\(\s*(?!KERN_[A-Z]+\b)/) {
WARN("PRINTK_WITHOUT_KERN_LEVEL",
"printk()
On 27/11/17 02:25 AM, Joe Perches wrote:
[]
diff -u -p a/lib/locking-selftest.c b/lib/locking-selftest.c
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -1186,7 +1186,7 @@ static void dotest(void (*testcase_fn)(v
static inline void print_testname(const char *testname)
{
-
On 27/11/17 02:25 AM, Joe Perches wrote:
[]
diff -u -p a/lib/locking-selftest.c b/lib/locking-selftest.c
--- a/lib/locking-selftest.c
+++ b/lib/locking-selftest.c
@@ -1186,7 +1186,7 @@ static void dotest(void (*testcase_fn)(v
static inline void print_testname(const char *testname)
{
-
On 27/11/17 01:52 AM, Julia Lawall wrote:
I meant why not only suggest pr_cont?
You could. Not much difference though, both are discouraged.
Logan
On 27/11/17 01:52 AM, Julia Lawall wrote:
I meant why not only suggest pr_cont?
You could. Not much difference though, both are discouraged.
Logan
On Mon, 2017-11-27 at 10:32 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Joe Perches wrote:
[]
> > below: the gig_dbg macro and _many_ other append a newline to a format
>
> Still, it seems that the file must contain a bug elsewhere, because the
> presence of this report means that some
On Mon, 2017-11-27 at 10:32 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Joe Perches wrote:
[]
> > below: the gig_dbg macro and _many_ other append a newline to a format
>
> Still, it seems that the file must contain a bug elsewhere, because the
> presence of this report means that some
On Mon, 27 Nov 2017, Joe Perches wrote:
> On Mon, 2017-11-27 at 07:08 +0100, Julia Lawall wrote:
> >
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> >
> > > On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > > > My semantic patch and results are below. The semantic patch has some
> > > >
On Mon, 27 Nov 2017, Joe Perches wrote:
> On Mon, 2017-11-27 at 07:08 +0100, Julia Lawall wrote:
> >
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> >
> > > On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > > > My semantic patch and results are below. The semantic patch has some
> > > >
On Mon, 2017-11-27 at 07:08 +0100, Julia Lawall wrote:
>
> On Sun, 26 Nov 2017, Joe Perches wrote:
>
> > On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > > My semantic patch and results are below. The semantic patch has some
> > > features that may or may not be desired:
> > >
> > >
On Mon, 2017-11-27 at 07:08 +0100, Julia Lawall wrote:
>
> On Sun, 26 Nov 2017, Joe Perches wrote:
>
> > On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > > My semantic patch and results are below. The semantic patch has some
> > > features that may or may not be desired:
> > >
> > >
On Mon, 2017-11-27 at 09:52 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Joe Perches wrote:
> > On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
> > > On 26/11/17 11:34 PM, Julia Lawall wrote:
> > > > It would probably be better not to mention the KERN_CONT possibility at
> > > >
On Mon, 2017-11-27 at 09:52 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Joe Perches wrote:
> > On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
> > > On 26/11/17 11:34 PM, Julia Lawall wrote:
> > > > It would probably be better not to mention the KERN_CONT possibility at
> > > >
On Mon, 2017-11-27 at 07:42 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Julia Lawall wrote:
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> > > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > > I just assume that a printk that has no KERN_ is adding a
> > > > newline, which is my
On Mon, 2017-11-27 at 07:42 +0100, Julia Lawall wrote:
> On Mon, 27 Nov 2017, Julia Lawall wrote:
> > On Sun, 26 Nov 2017, Joe Perches wrote:
> > > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > > I just assume that a printk that has no KERN_ is adding a
> > > > newline, which is my
On Mon, 27 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
> >
> > On 26/11/17 11:34 PM, Julia Lawall wrote:
> > > It would probably be better not to mention the KERN_CONT possibility at
> > > all.
> >
> > Oh? I don't disagree... but what are we supposed
On Mon, 27 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
> >
> > On 26/11/17 11:34 PM, Julia Lawall wrote:
> > > It would probably be better not to mention the KERN_CONT possibility at
> > > all.
> >
> > Oh? I don't disagree... but what are we supposed
On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
>
> On 26/11/17 11:34 PM, Julia Lawall wrote:
> > It would probably be better not to mention the KERN_CONT possibility at
> > all.
>
> Oh? I don't disagree... but what are we supposed to do in these cases?
> The way v2 of my patch works
On Sun, 2017-11-26 at 23:40 -0700, Logan Gunthorpe wrote:
>
> On 26/11/17 11:34 PM, Julia Lawall wrote:
> > It would probably be better not to mention the KERN_CONT possibility at
> > all.
>
> Oh? I don't disagree... but what are we supposed to do in these cases?
> The way v2 of my patch works
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 11:42 PM, Julia Lawall wrote:
> > Although I guess that in that case the whole exercise is pointless?
> > Because every print will at runtime be followed by another print, which
> > will add either the newline or a continuation.
>
>
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 11:42 PM, Julia Lawall wrote:
> > Although I guess that in that case the whole exercise is pointless?
> > Because every print will at runtime be followed by another print, which
> > will add either the newline or a continuation.
>
>
On 26/11/17 11:42 PM, Julia Lawall wrote:
> Although I guess that in that case the whole exercise is pointless?
> Because every print will at runtime be followed by another print, which
> will add either the newline or a continuation.
Yes, in practice the '\n' at the end of every log line is
On 26/11/17 11:42 PM, Julia Lawall wrote:
> Although I guess that in that case the whole exercise is pointless?
> Because every print will at runtime be followed by another print, which
> will add either the newline or a continuation.
Yes, in practice the '\n' at the end of every log line is
On Mon, 27 Nov 2017, Julia Lawall wrote:
>
>
> On Sun, 26 Nov 2017, Joe Perches wrote:
>
> > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > I just assume that a printk that has no KERN_ is adding a
> > > newline, which is my understanding of Joe's comment.
> >
> > More precisely:
On Mon, 27 Nov 2017, Julia Lawall wrote:
>
>
> On Sun, 26 Nov 2017, Joe Perches wrote:
>
> > On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > > I just assume that a printk that has no KERN_ is adding a
> > > newline, which is my understanding of Joe's comment.
> >
> > More precisely:
On 26/11/17 11:34 PM, Julia Lawall wrote:
> It would probably be better not to mention the KERN_CONT possibility at
> all.
Oh? I don't disagree... but what are we supposed to do in these cases?
The way v2 of my patch works it just says that there is a missing new
line. But Joe calls that a
On 26/11/17 11:34 PM, Julia Lawall wrote:
> It would probably be better not to mention the KERN_CONT possibility at
> all.
Oh? I don't disagree... but what are we supposed to do in these cases?
The way v2 of my patch works it just says that there is a missing new
line. But Joe calls that a
On Sun, 26 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > I just assume that a printk that has no KERN_ is adding a
> > newline, which is my understanding of Joe's comment.
>
> More precisely:
>
> Any printk without an initial KERN_CONT prepends a
On Sun, 26 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> > I just assume that a printk that has no KERN_ is adding a
> > newline, which is my understanding of Joe's comment.
>
> More precisely:
>
> Any printk without an initial KERN_CONT prepends a
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 11:11 PM, Julia Lawall wrote:
> > I don't have a different warning if the string ends in a space. I have a
> > different warning when one possible control-flow path is fine and another
> > control-flow path is not. The space thing
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 11:11 PM, Julia Lawall wrote:
> > I don't have a different warning if the string ends in a space. I have a
> > different warning when one possible control-flow path is fine and another
> > control-flow path is not. The space thing
On 26/11/17 11:11 PM, Julia Lawall wrote:
> I don't have a different warning if the string ends in a space. I have a
> different warning when one possible control-flow path is fine and another
> control-flow path is not. The space thing relates to guessing whether
> some other printing API
On 26/11/17 11:11 PM, Julia Lawall wrote:
> I don't have a different warning if the string ends in a space. I have a
> different warning when one possible control-flow path is fine and another
> control-flow path is not. The space thing relates to guessing whether
> some other printing API
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 03:29 PM, Joe Perches wrote:
> > This proposal has a very high false positive rate.
>
> The only actual false positive you've pointed out is the one that is
> just incorrect in the wrong way (the author should have used a KERN_CONT
>
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 03:29 PM, Joe Perches wrote:
> > This proposal has a very high false positive rate.
>
> The only actual false positive you've pointed out is the one that is
> just incorrect in the wrong way (the author should have used a KERN_CONT
>
On Sun, 26 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > My semantic patch and results are below. The semantic patch has some
> > features that may or may not be desired:
> >
> > 1. It goes beyond printk, pr_xxx, dev_xxx, and netdev_xxx, by finding
On Sun, 26 Nov 2017, Joe Perches wrote:
> On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> > My semantic patch and results are below. The semantic patch has some
> > features that may or may not be desired:
> >
> > 1. It goes beyond printk, pr_xxx, dev_xxx, and netdev_xxx, by finding
On 26/11/17 03:29 PM, Joe Perches wrote:
> This proposal has a very high false positive rate.
The only actual false positive you've pointed out is the one that is
just incorrect in the wrong way (the author should have used a KERN_CONT
but did not). I could easily do something similar to what
On 26/11/17 03:29 PM, Joe Perches wrote:
> This proposal has a very high false positive rate.
The only actual false positive you've pointed out is the one that is
just incorrect in the wrong way (the author should have used a KERN_CONT
but did not). I could easily do something similar to what
On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> I just assume that a printk that has no KERN_ is adding a
> newline, which is my understanding of Joe's comment.
More precisely:
Any printk without an initial KERN_CONT prepends a newline
if the last printk content char emitted that is not
On Sun, 2017-11-26 at 19:17 +0100, Julia Lawall wrote:
> I just assume that a printk that has no KERN_ is adding a
> newline, which is my understanding of Joe's comment.
More precisely:
Any printk without an initial KERN_CONT prepends a newline
if the last printk content char emitted that is not
On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> My semantic patch and results are below. The semantic patch has some
> features that may or may not be desired:
>
> 1. It goes beyond printk, pr_xxx, dev_xxx, and netdev_xxx, by finding
> functions that are sometimes used with a format
On Sun, 2017-11-26 at 23:44 +0100, Julia Lawall wrote:
> My semantic patch and results are below. The semantic patch has some
> features that may or may not be desired:
>
> 1. It goes beyond printk, pr_xxx, dev_xxx, and netdev_xxx, by finding
> functions that are sometimes used with a format
On Sun, 2017-11-26 at 10:38 -0700, Logan Gunthorpe wrote:
>
> On 25/11/17 11:01 PM, Joe Perches wrote:
> > It doesn't really work.
>
> That's rather hyperbolic and I don't appreciate the tone.
What I wrote is neither hyperbolic nor tonal.
I'm rather familiar with checkpatch.
High false
On Sun, 2017-11-26 at 10:38 -0700, Logan Gunthorpe wrote:
>
> On 25/11/17 11:01 PM, Joe Perches wrote:
> > It doesn't really work.
>
> That's rather hyperbolic and I don't appreciate the tone.
What I wrote is neither hyperbolic nor tonal.
I'm rather familiar with checkpatch.
High false
On 26/11/17 11:17 AM, Julia Lawall wrote:
> The main limitation that is likely to remain in my script is that
> Coccinelle doesn't always understand ifdefs properly. So
> #ifdef
> printk("xxx");
> #else
> printk("yyy");
> #endif
> pr_cont("zzz");
>
> may give a warning about the first printk.
On 26/11/17 11:17 AM, Julia Lawall wrote:
> The main limitation that is likely to remain in my script is that
> Coccinelle doesn't always understand ifdefs properly. So
> #ifdef
> printk("xxx");
> #else
> printk("yyy");
> #endif
> pr_cont("zzz");
>
> may give a warning about the first printk.
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 10:09 AM, Julia Lawall wrote:
> > I don't know. In any case, a Coccinelle script would get run by the 0-day
> > build testing service, which checks lots of trees. Perhaps both are
> > useful, since Joe had some conerns about the
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 26/11/17 10:09 AM, Julia Lawall wrote:
> > I don't know. In any case, a Coccinelle script would get run by the 0-day
> > build testing service, which checks lots of trees. Perhaps both are
> > useful, since Joe had some conerns about the
On 26/11/17 10:09 AM, Julia Lawall wrote:
> I don't know. In any case, a Coccinelle script would get run by the 0-day
> build testing service, which checks lots of trees. Perhaps both are
> useful, since Joe had some conerns about the amount of relevant context
> available in a patch.
Yup,
On 26/11/17 10:09 AM, Julia Lawall wrote:
> I don't know. In any case, a Coccinelle script would get run by the 0-day
> build testing service, which checks lots of trees. Perhaps both are
> useful, since Joe had some conerns about the amount of relevant context
> available in a patch.
Yup,
On 25/11/17 11:01 PM, Joe Perches wrote:
> It doesn't really work.
That's rather hyperbolic and I don't appreciate the tone.
> Many of the messages aren't missing newlines.
>
> I only looked a the first few dozen instances, but many of
> them aren't really missing newlines, but are now
On 25/11/17 11:01 PM, Joe Perches wrote:
> It doesn't really work.
That's rather hyperbolic and I don't appreciate the tone.
> Many of the messages aren't missing newlines.
>
> I only looked a the first few dozen instances, but many of
> them aren't really missing newlines, but are now
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 25/11/17 10:51 PM, Julia Lawall wrote:
> > I don't understand at all the second sentence. Are you staying with the
> > same call, or moving on to other calls? Also, it would be the call that
> > is split over multiple lines, not the
On Sun, 26 Nov 2017, Logan Gunthorpe wrote:
>
>
> On 25/11/17 10:51 PM, Julia Lawall wrote:
> > I don't understand at all the second sentence. Are you staying with the
> > same call, or moving on to other calls? Also, it would be the call that
> > is split over multiple lines, not the
On 25/11/17 10:51 PM, Julia Lawall wrote:
> I don't understand at all the second sentence. Are you staying with the
> same call, or moving on to other calls? Also, it would be the call that
> is split over multiple lines, not the function split over multiple lines.
Yes, you are correct it
On 25/11/17 10:51 PM, Julia Lawall wrote:
> I don't understand at all the second sentence. Are you staying with the
> same call, or moving on to other calls? Also, it would be the call that
> is split over multiple lines, not the function split over multiple lines.
Yes, you are correct it
On Sun, 2017-11-26 at 06:51 +0100, Julia Lawall wrote:
>
> On Sat, 25 Nov 2017, Logan Gunthorpe wrote:
>
> > Check for lines with a log function using a relatively strict regular
> > expression catching only printk, dev_* and pr_* functions. Once
> > one is found, accumulate further lines for
On Sun, 2017-11-26 at 06:51 +0100, Julia Lawall wrote:
>
> On Sat, 25 Nov 2017, Logan Gunthorpe wrote:
>
> > Check for lines with a log function using a relatively strict regular
> > expression catching only printk, dev_* and pr_* functions. Once
> > one is found, accumulate further lines for
On Sat, 25 Nov 2017, Logan Gunthorpe wrote:
> Check for lines with a log function using a relatively strict regular
> expression catching only printk, dev_* and pr_* functions. Once
> one is found, accumulate further lines for any functions that
> are split over multiple lines.
I don't
On Sat, 25 Nov 2017, Logan Gunthorpe wrote:
> Check for lines with a log function using a relatively strict regular
> expression catching only printk, dev_* and pr_* functions. Once
> one is found, accumulate further lines for any functions that
> are split over multiple lines.
I don't
88 matches
Mail list logo
