> Do symbols which are not exported (no EXPORT_SYMBOL_(GPL)) cause conflicts?
How do you think about to mark more functions from your software module
as static?
> I was under the impression that those are module private.
> If they are indeed private then I would prefer to not rename them.
Do symbols which are not exported (no EXPORT_SYMBOL_(GPL)) cause conflicts?
How do you think about to mark more functions from your software module
as static?
I was under the impression that those are module private.
If they are indeed private then I would prefer to not rename them.
Would
On Sun, 2014-11-23 at 20:03 +0100, SF Markus Elfring wrote:
> > Why not just make the static source code analysis aware of the problem?
>
> This is also possible, of course.
>
>
> > You can treat static functions differently that non-static ones.
>
> I have added this detail to my ideas around
> Why not just make the static source code analysis aware of the problem?
This is also possible, of course.
> You can treat static functions differently that non-static ones.
I have added this detail to my ideas around the next fine-tuning
for the published semantic patch approach.
> There
On Sun, 2014-11-23 at 16:45 +0100, Andreas Noever wrote:
> On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches wrote:
> > On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
> >> >> 2. Are any additional prefixes appropriate so that further name space
> >> >>conflicts can be better avoided?
On Sun, 23 Nov 2014, SF Markus Elfring wrote:
> >> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268
> >
> > I think static functions can be named whatever
> > the developer chooses.
>
> I
On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches wrote:
> On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
>> >> 2. Are any additional prefixes appropriate so that further name space
>> >>conflicts can be better avoided?
>> >
>> > To avoid possible external naming conflicts, add tb_
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268
>
> I think static functions can be named whatever
> the developer chooses.
I agree also that this implementation detail is correct in
On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
> >> 2. Are any additional prefixes appropriate so that further name space
> >>conflicts can be better avoided?
> >
> > To avoid possible external naming conflicts, add tb_ prefix to
> > various ring_ structs and functions.
>
> Do
>> 2. Are any additional prefixes appropriate so that further name space
>>conflicts can be better avoided?
>
> To avoid possible external naming conflicts, add tb_ prefix to
> various ring_ structs and functions.
Do you imagine that any XEN software developers need also to reconsider
this
2. Are any additional prefixes appropriate so that further name space
conflicts can be better avoided?
To avoid possible external naming conflicts, add tb_ prefix to
various ring_foo structs and functions.
Do you imagine that any XEN software developers need also to reconsider
this
On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
2. Are any additional prefixes appropriate so that further name space
conflicts can be better avoided?
To avoid possible external naming conflicts, add tb_ prefix to
various ring_foo structs and functions.
Do you imagine
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268
I think static functions can be named whatever
the developer chooses.
I agree also that this implementation detail is correct in
On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches j...@perches.com wrote:
On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
2. Are any additional prefixes appropriate so that further name space
conflicts can be better avoided?
To avoid possible external naming conflicts, add tb_
On Sun, 23 Nov 2014, SF Markus Elfring wrote:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/drivers/char/tpm/xen-tpmfront.c?id=fc14f9c1272f62c3e8d01300f52467c0d9af50f9#n268
I think static functions can be named whatever
the developer chooses.
I agree also
On Sun, 2014-11-23 at 16:45 +0100, Andreas Noever wrote:
On Sun, Nov 23, 2014 at 4:20 PM, Joe Perches j...@perches.com wrote:
On Sun, 2014-11-23 at 15:14 +0100, SF Markus Elfring wrote:
2. Are any additional prefixes appropriate so that further name space
conflicts can be better
Why not just make the static source code analysis aware of the problem?
This is also possible, of course.
You can treat static functions differently that non-static ones.
I have added this detail to my ideas around the next fine-tuning
for the published semantic patch approach.
There is
On Sun, 2014-11-23 at 20:03 +0100, SF Markus Elfring wrote:
Why not just make the static source code analysis aware of the problem?
This is also possible, of course.
You can treat static functions differently that non-static ones.
I have added this detail to my ideas around the next
On Fri, 2014-11-21 at 13:21 +0100, SF Markus Elfring wrote:
> 2. Are any additional prefixes appropriate so that further name space
>conflicts can be better avoided?
To avoid possible external naming conflicts, add tb_ prefix to
various ring_ structs and functions.
Other miscellanea:
o
> ring_free does not check for null:
> http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398
>
> Maybe your software confuses the method with:
> http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268
Thanks for your feedback.
I am sorry for a bit of confusion
Hi Markus,
ring_free does not check for null:
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398
Maybe your software confuses the method with:
http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268
Andreas
On Fri, Nov 21, 2014 at 11:40 AM, SF Markus Elfring
From: Markus Elfring
Date: Fri, 21 Nov 2014 11:30:18 +0100
The ring_free() 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
---
From: Markus Elfring elfr...@users.sourceforge.net
Date: Fri, 21 Nov 2014 11:30:18 +0100
The ring_free() 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.
Hi Markus,
ring_free does not check for null:
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398
Maybe your software confuses the method with:
http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268
Andreas
On Fri, Nov 21, 2014 at 11:40 AM, SF Markus Elfring
ring_free does not check for null:
http://lxr.free-electrons.com/source/drivers/thunderbolt/nhi.c#L398
Maybe your software confuses the method with:
http://lxr.free-electrons.com/source/drivers/char/tpm/xen-tpmfront.c#L268
Thanks for your feedback.
I am sorry for a bit of confusion here.
On Fri, 2014-11-21 at 13:21 +0100, SF Markus Elfring wrote:
2. Are any additional prefixes appropriate so that further name space
conflicts can be better avoided?
To avoid possible external naming conflicts, add tb_ prefix to
various ring_foo structs and functions.
Other miscellanea:
o
26 matches
Mail list logo
