> > > Perhaps this "x =" should also include += and +
> > > and the various other operators that are possible
> > > or does SmPL grammar already do that?
This is now done. It seems to have had no impact.
> Anywhere the return value of strlcpy is used, not just as
> an assignment, is an instance
> Huh? Rule 2 is important, to ensure that ths size is correct.
I assume that the dependency of the replacement on the data structure check
can become clearer.
Regards,
Markus
On Thu, 2019-07-25 at 08:58 -0500, Julia Lawall wrote:
> On Thu, 25 Jul 2019, Joe Perches wrote:
[]
> > Just for completeness and correctness, as I at
> > least don't find an existing use:
> >
> > Perhaps this "x =" should also include += and +
> > and the various other operators that are
On Thu, 25 Jul 2019, Joe Perches wrote:
> On Wed, 2019-07-24 at 20:42 -0500, Julia Lawall wrote:
> > New version. I check for non-use of the return value of strlcpy and
> > address some issues that affected the matching of the case where the first
> > argument involves a pointer dereference.
On Wed, 2019-07-24 at 20:42 -0500, Julia Lawall wrote:
> New version. I check for non-use of the return value of strlcpy and
> address some issues that affected the matching of the case where the first
> argument involves a pointer dereference. Actually, an isomorphism now
> takes care of that
On Thu, 25 Jul 2019, Markus Elfring wrote:
> > @r@
> > identifier f,i1,i2;
> > struct i1 e1;
> > expression e2;
> > position p;
> > @@
> > \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
>
> I have got the impression that the replacement can work also
> without an inherited position variable at the end.
> @r@
> identifier f,i1,i2;
> struct i1 e1;
> expression e2;
> position p;
> @@
> \(strscpy\|strlcpy\)(e1.f, e2, i2)@p
I have got the impression that the replacement can work also
without an inherited position variable at the end.
How do you think about to omit this SmPL rule then?
Can it be
>>> @@
>>> (
>>> -x = strlcpy
>>> +stracpy
>>> (e1.f, e2
>>> -, i2
>>> )@p;
>>> ... when != x
>>>
>>> |
>>
>> I wonder about the deletion of the assignment target.
>> Should the setting of such a variable be usually preserved?
>
> If it is a local variable and never subsequently used, it
On Thu, 25 Jul 2019, Markus Elfring wrote:
> > New version. I check for non-use of the return value of strlcpy and
> > address some issues that affected the matching of the case where the first
> > argument involves a pointer dereference.
>
> I suggest to take another look at corresponding
On Thu, 25 Jul 2019, Matthias Maennich wrote:
> Add the missing GPLv2 SPDX license identifier.
>
> It appears this single file was missing from 7f904d7e1f3e ("treewide:
> Replace GPLv2 boilerplate/reference with SPDX - rule 505"), which
> addressed all other files in scripts/coccinelle. Hence
On Thu, Jul 25, 2019 at 11:17:04AM +0100, Matthias Maennich wrote:
> Add the missing GPLv2 SPDX license identifier.
>
> It appears this single file was missing from 7f904d7e1f3e ("treewide:
> Replace GPLv2 boilerplate/reference with SPDX - rule 505"), which
> addressed all other files in
Add the missing GPLv2 SPDX license identifier.
It appears this single file was missing from 7f904d7e1f3e ("treewide:
Replace GPLv2 boilerplate/reference with SPDX - rule 505"), which
addressed all other files in scripts/coccinelle. Hence I added
GPL-2.0-only consitently with the mentioned patch.
> New version. I check for non-use of the return value of strlcpy and
> address some issues that affected the matching of the case where the first
> argument involves a pointer dereference.
I suggest to take another look at corresponding implementation details
of the shown SmPL script.
>
13 matches
Mail list logo
