Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> Are there any risks to include too many functions? > > Maybe if there are conflicting definitions of the function with different > return types. This is probably not a big deal in practice. Are there any more concerns around the handling of conditional source code analysis for Linux subsystems? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > >> * Will a command-line parameter like "--include-headers-for-types" > >> be needed here? > > > > This argument is never needed. It is only an optimization. It means that > > he header files are only considered when collecting type information, but > > not whn doing transformation. But this argument has no effect on the set > > of types tha are available. > > I would consider the reuse of the parameter "--recursive-includes" then > so that the most function signatures will be available. > This has got some consequences on the execution speed and configuration > for the source code analysis. > > Are there any risks to include too many functions? Maybe if there are conflicting definitions of the function with different return types. This is probably not a big deal in practice. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> * Will a command-line parameter like "--include-headers-for-types" >> be needed here? > > This argument is never needed. It is only an optimization. It means that > he header files are only considered when collecting type information, but > not whn doing transformation. But this argument has no effect on the set > of types tha are available. I would consider the reuse of the parameter "--recursive-includes" then so that the most function signatures will be available. This has got some consequences on the execution speed and configuration for the source code analysis. Are there any risks to include too many functions? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > > It doesn't matter, as long as the type is available. > > I suggest to make the circumstances better known when this will be the case. It is like for the type of anything. If the declaration of the thing is available with the type information, eg in the same file or an included header file, then the type will be available. If the declaration is not available then the type will not be available. > >> How do you think about reuse another data type enumeration there? > > > > No idea what you mean by this. > > A SmPL variable can also be connected with a data type list which is > discussed here. One type, more that one type, it doesn't matter. > >> How would you like to manage names for functions which are not defined > >> in the current source file? > > > > Why does it matter in this case? > > * Will a command-line parameter like "--include-headers-for-types" > be needed here? This argument is never needed. It is only an optimization. It means that he header files are only considered when collecting type information, but not whn doing transformation. But this argument has no effect on the set of types tha are available. julia > * Would it make sense to work with function name lists in SmPL constraints? > > > Will any fine-tuning be needed for the execution speed of the evolving > source code analysis? > > Regards, > Markus > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> It doesn't matter, as long as the type is available. I suggest to make the circumstances better known when this will be the case. >> How do you think about reuse another data type enumeration there? > > No idea what you mean by this. A SmPL variable can also be connected with a data type list which is discussed here. >> How would you like to manage names for functions which are not defined >> in the current source file? > > Why does it matter in this case? * Will a command-line parameter like "--include-headers-for-types" be needed here? * Would it make sense to work with function name lists in SmPL constraints? Will any fine-tuning be needed for the execution speed of the evolving source code analysis? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > >> The connection between the SmPL specification "f(...)@e" and the desired > >> return type > >> was not obvious for me so far. > > > > The nearest enclosing expression of the ) is the whole function call itself. > > Thanks for your explanation. > > Now I guess that the enclosing context is a particular function implementation > where specific calls are performed, isn't it? No idea what yu mean by this. Function calls are usually found within function definitions. But it could be in the definition of a macro as well. It doesn't matter, as long as the type is available. > > > > e will thus match the entire expression. e is declared to have type t > > Did you omit this detail in your suggestion a moment ago? I don't thik so. I said t e; where t could be whatever typep or set of types one wants. > > > (where t is in practice signed int or whatever one wants to check for). > > How do you think about reuse another data type enumeration there? No idea what you mean by this. > > How would you like to manage names for functions which are not defined > in the current source file? Why does it matter in this case? julia > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> The connection between the SmPL specification "f(...)@e" and the desired >> return type >> was not obvious for me so far. > > The nearest enclosing expression of the ) is the whole function call itself. Thanks for your explanation. Now I guess that the enclosing context is a particular function implementation where specific calls are performed, isn't it? > e will thus match the entire expression. e is declared to have type t Did you omit this detail in your suggestion a moment ago? > (where t is in practice signed int or whatever one wants to check for). How do you think about reuse another data type enumeration there? How would you like to manage names for functions which are not defined in the current source file? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > > Your approach finds a function definition. > > Yes. - I assumed that it might also be relevant. > > > > > My approach works on the call directly, using whatever type information is > > available. > > The connection between the SmPL specification "f(...)@e" and the desired > return type > was not obvious for me so far. The nearest enclosing expression of the ) is the whole function call itself. e will thus match the entire expression. e is declared to have type t (where t is in practice signed int or whatever one wants to check for). julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> Your approach finds a function definition. Yes. - I assumed that it might also be relevant. > My approach works on the call directly, using whatever type information is > available. The connection between the SmPL specification "f(...)@e" and the desired return type was not obvious for me so far. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote:
> > To collect function calls that have a return value of a given type t,
> > it should be sufficient to do the following:
> >
> > @@
> > t e;
> > identifier f;
> > @@
> >
> > f(...)@e
>
> Is such a SmPL approach better than a variant like the following?
>
> @find_function@
> type t;
> identifier f;
> @@
> t f(...)
> { ... }
Your approach finds a function definition. My approach works on the call
directly, using whatever type information is available.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> To collect function calls that have a return value of a given type t,
> it should be sufficient to do the following:
>
> @@
> t e;
> identifier f;
> @@
>
> f(...)@e
Is such a SmPL approach better than a variant like the following?
@find_function@
type t;
identifier f;
@@
t f(...)
{ ... }
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
To collect function calls that have a return value of a given type t, it should be sufficient to do the following: @@ t e; identifier f; @@ f(...)@e The @e notation reaches upwards to match the innermost enclosing term of the right kind (here expression). t can of course be arbitrarily complicated. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> Generally I want to catch all assignments of signed function result to > unsigned var. Such a static source code analysis will be useful to some degree. > In this script I have implemented it this way: > 1. Look for all assignments 'unsigned = signed' (rs rule). > 2. Check if signed from rs rule looks as a function call. I recommend to reconsider a few implementation details because I have got the impression that this check sequence is inappropriate. > Is there better way to do it? I suggest to fix expression weaknesses and a design mistake in this SmPL approach. I guess that you want to determine functions with a signed return type first before corresponding variable assignments will be checked further. * Would you like to collect function names for this purpose by a general analysis of more source files? (How do you think about to store them in a dedicated database?) * Which couple of function calls will be interesting for you? * Should the search approach take also recursively included files into account? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> To collect function calls that have a return value of a given type t,
> it should be sufficient to do the following:
>
> @@
> t e;
> identifier f;
> @@
>
> f(...)@e
Is such a SmPL approach better than a variant like the following?
@find_function@
type t;
identifier f;
@@
t f(...)
{ ... }
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote:
> > To collect function calls that have a return value of a given type t,
> > it should be sufficient to do the following:
> >
> > @@
> > t e;
> > identifier f;
> > @@
> >
> > f(...)@e
>
> Is such a SmPL approach better than a variant like the following?
>
> @find_function@
> type t;
> identifier f;
> @@
> t f(...)
> { ... }
Your approach finds a function definition. My approach works on the call
directly, using whatever type information is available.
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> Generally I want to catch all assignments of signed function result to > unsigned var. Such a static source code analysis will be useful to some degree. > In this script I have implemented it this way: > 1. Look for all assignments 'unsigned = signed' (rs rule). > 2. Check if signed from rs rule looks as a function call. I recommend to reconsider a few implementation details because I have got the impression that this check sequence is inappropriate. > Is there better way to do it? I suggest to fix expression weaknesses and a design mistake in this SmPL approach. I guess that you want to determine functions with a signed return type first before corresponding variable assignments will be checked further. * Would you like to collect function names for this purpose by a general analysis of more source files? (How do you think about to store them in a dedicated database?) * Which couple of function calls will be interesting for you? * Should the search approach take also recursively included files into account? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> The connection between the SmPL specification "f(...)@e" and the desired >> return type >> was not obvious for me so far. > > The nearest enclosing expression of the ) is the whole function call itself. Thanks for your explanation. Now I guess that the enclosing context is a particular function implementation where specific calls are performed, isn't it? > e will thus match the entire expression. e is declared to have type t Did you omit this detail in your suggestion a moment ago? > (where t is in practice signed int or whatever one wants to check for). How do you think about reuse another data type enumeration there? How would you like to manage names for functions which are not defined in the current source file? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> Your approach finds a function definition. Yes. - I assumed that it might also be relevant. > My approach works on the call directly, using whatever type information is > available. The connection between the SmPL specification "f(...)@e" and the desired return type was not obvious for me so far. Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > >> The connection between the SmPL specification "f(...)@e" and the desired > >> return type > >> was not obvious for me so far. > > > > The nearest enclosing expression of the ) is the whole function call itself. > > Thanks for your explanation. > > Now I guess that the enclosing context is a particular function implementation > where specific calls are performed, isn't it? No idea what yu mean by this. Function calls are usually found within function definitions. But it could be in the definition of a macro as well. It doesn't matter, as long as the type is available. > > > > e will thus match the entire expression. e is declared to have type t > > Did you omit this detail in your suggestion a moment ago? I don't thik so. I said t e; where t could be whatever typep or set of types one wants. > > > (where t is in practice signed int or whatever one wants to check for). > > How do you think about reuse another data type enumeration there? No idea what you mean by this. > > How would you like to manage names for functions which are not defined > in the current source file? Why does it matter in this case? julia > Regards, > Markus > -- > To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > >> * Will a command-line parameter like "--include-headers-for-types" > >> be needed here? > > > > This argument is never needed. It is only an optimization. It means that > > he header files are only considered when collecting type information, but > > not whn doing transformation. But this argument has no effect on the set > > of types tha are available. > > I would consider the reuse of the parameter "--recursive-includes" then > so that the most function signatures will be available. > This has got some consequences on the execution speed and configuration > for the source code analysis. > > Are there any risks to include too many functions? Maybe if there are conflicting definitions of the function with different return types. This is probably not a big deal in practice. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> It doesn't matter, as long as the type is available. I suggest to make the circumstances better known when this will be the case. >> How do you think about reuse another data type enumeration there? > > No idea what you mean by this. A SmPL variable can also be connected with a data type list which is discussed here. >> How would you like to manage names for functions which are not defined >> in the current source file? > > Why does it matter in this case? * Will a command-line parameter like "--include-headers-for-types" be needed here? * Would it make sense to work with function name lists in SmPL constraints? Will any fine-tuning be needed for the execution speed of the evolving source code analysis? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
To collect function calls that have a return value of a given type t, it should be sufficient to do the following: @@ t e; identifier f; @@ f(...)@e The @e notation reaches upwards to match the innermost enclosing term of the right kind (here expression). t can of course be arbitrarily complicated. julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > > Your approach finds a function definition. > > Yes. - I assumed that it might also be relevant. > > > > > My approach works on the call directly, using whatever type information is > > available. > > The connection between the SmPL specification "f(...)@e" and the desired > return type > was not obvious for me so far. The nearest enclosing expression of the ) is the whole function call itself. e will thus match the entire expression. e is declared to have type t (where t is in practice signed int or whatever one wants to check for). julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On Sat, 26 Sep 2015, SF Markus Elfring wrote: > > It doesn't matter, as long as the type is available. > > I suggest to make the circumstances better known when this will be the case. It is like for the type of anything. If the declaration of the thing is available with the type information, eg in the same file or an included header file, then the type will be available. If the declaration is not available then the type will not be available. > >> How do you think about reuse another data type enumeration there? > > > > No idea what you mean by this. > > A SmPL variable can also be connected with a data type list which is > discussed here. One type, more that one type, it doesn't matter. > >> How would you like to manage names for functions which are not defined > >> in the current source file? > > > > Why does it matter in this case? > > * Will a command-line parameter like "--include-headers-for-types" > be needed here? This argument is never needed. It is only an optimization. It means that he header files are only considered when collecting type information, but not whn doing transformation. But this argument has no effect on the set of types tha are available. julia > * Would it make sense to work with function name lists in SmPL constraints? > > > Will any fine-tuning be needed for the execution speed of the evolving > source code analysis? > > Regards, > Markus > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> Are there any risks to include too many functions? > > Maybe if there are conflicting definitions of the function with different > return types. This is probably not a big deal in practice. Are there any more concerns around the handling of conditional source code analysis for Linux subsystems? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>> * Will a command-line parameter like "--include-headers-for-types" >> be needed here? > > This argument is never needed. It is only an optimization. It means that > he header files are only considered when collecting type information, but > not whn doing transformation. But this argument has no effect on the set > of types tha are available. I would consider the reuse of the parameter "--recursive-includes" then so that the most function signatures will be available. This has got some consequences on the execution speed and configuration for the source code analysis. Are there any risks to include too many functions? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>>> +@rs@
>>> +position p;
>>> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
>>> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
>> Can it matter to specify also the type modifier "signed" in this SmPL
>> approach?
>> http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
> According to my tests it does not matter.
> Btw I should replace short int, with short,
I have got an other view on such an implementation detail around
explicit SmPL specifications.
> to allow catch short intergers.
Do you assume that the Coccinelle software will handle more data type
variants for you automatically?
>>> +@@
>>> +
>>> +vu@p = vs
>>> +
>>> +@r@
>>> +position rs.p;
>>> +identifier v, f;
>>> +statement S1, S2;
>>> +expression e;
>>> +@@
>>> +
>>> +*v@p = f(...);
>> Do you try to check here if the value receiver is at the same source code
>> position from the SmPL rule "rs"?
> Yes.
I imagine that there is an open issue in this SmPL approach then.
How should a return value from a function call and a variable access
work at the same place?
> Is there better way to do it?
Do you need to distinguish source code positions a bit more with
corresponding SmPL variables?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On 09/24/2015 05:51 PM, SF Markus Elfring wrote:
>> +@rs@
>> +position p;
>> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
>> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
> Can it matter to specify also the type modifier "signed" in this SmPL
> approach?
> http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
According to my tests it does not matter.
Btw I should replace short int, with short, to allow catch short intergers.
>
>
>> +{unsigned char, unsigned short, unsigned int, unsigned long, unsigned long
>> long, size_t, bool, u8, u16, u32, u64} vu;
> How do you think about to reformat such a data type enumeration?
If you mean split line to be below 80 chars, OK.
>
>
>> +@@
>> +
>> +vu@p = vs
>> +
>> +@r@
>> +position rs.p;
>> +identifier v, f;
>> +statement S1, S2;
>> +expression e;
>> +@@
>> +
>> +*v@p = f(...);
> Do you try to check here if the value receiver is at the same source code
> position from the SmPL rule "rs"?
Yes.
Generally I want to catch all assignments of signed function result to unsigned
var.
In this script I have implemented it this way:
1. Look for all assignments 'unsigned = signed' (rs rule).
2. Check if signed from rs rule looks as a function call.
Is there better way to do it?
Regards
Andrzej
>
> Regards,
> Markus
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
>>> +@rs@
>>> +position p;
>>> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
>>> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
>> Can it matter to specify also the type modifier "signed" in this SmPL
>> approach?
>> http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
> According to my tests it does not matter.
> Btw I should replace short int, with short,
I have got an other view on such an implementation detail around
explicit SmPL specifications.
> to allow catch short intergers.
Do you assume that the Coccinelle software will handle more data type
variants for you automatically?
>>> +@@
>>> +
>>> +vu@p = vs
>>> +
>>> +@r@
>>> +position rs.p;
>>> +identifier v, f;
>>> +statement S1, S2;
>>> +expression e;
>>> +@@
>>> +
>>> +*v@p = f(...);
>> Do you try to check here if the value receiver is at the same source code
>> position from the SmPL rule "rs"?
> Yes.
I imagine that there is an open issue in this SmPL approach then.
How should a return value from a function call and a variable access
work at the same place?
> Is there better way to do it?
Do you need to distinguish source code positions a bit more with
corresponding SmPL variables?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
On 09/24/2015 05:51 PM, SF Markus Elfring wrote:
>> +@rs@
>> +position p;
>> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
>> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
> Can it matter to specify also the type modifier "signed" in this SmPL
> approach?
> http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
According to my tests it does not matter.
Btw I should replace short int, with short, to allow catch short intergers.
>
>
>> +{unsigned char, unsigned short, unsigned int, unsigned long, unsigned long
>> long, size_t, bool, u8, u16, u32, u64} vu;
> How do you think about to reformat such a data type enumeration?
If you mean split line to be below 80 chars, OK.
>
>
>> +@@
>> +
>> +vu@p = vs
>> +
>> +@r@
>> +position rs.p;
>> +identifier v, f;
>> +statement S1, S2;
>> +expression e;
>> +@@
>> +
>> +*v@p = f(...);
> Do you try to check here if the value receiver is at the same source code
> position from the SmPL rule "rs"?
Yes.
Generally I want to catch all assignments of signed function result to unsigned
var.
In this script I have implemented it this way:
1. Look for all assignments 'unsigned = signed' (rs rule).
2. Check if signed from rs rule looks as a function call.
Is there better way to do it?
Regards
Andrzej
>
> Regards,
> Markus
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> +@rs@
> +position p;
> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
Can it matter to specify also the type modifier "signed" in this SmPL approach?
http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
> +{unsigned char, unsigned short, unsigned int, unsigned long, unsigned long
> long, size_t, bool, u8, u16, u32, u64} vu;
How do you think about to reformat such a data type enumeration?
> +@@
> +
> +vu@p = vs
> +
> +@r@
> +position rs.p;
> +identifier v, f;
> +statement S1, S2;
> +expression e;
> +@@
> +
> +*v@p = f(...);
Do you try to check here if the value receiver is at the same source code
position from the SmPL rule "rs"?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] coccinelle: assign signed result to unsigned variable
> +@rs@
> +position p;
> +typedef bool, u8, u16, u32, u64, s8, s16, s32, s64;
> +{char, short int, int, long, long long, s8, s16, s32, s64} vs;
Can it matter to specify also the type modifier "signed" in this SmPL approach?
http://coccinelle.lip6.fr/docs/main_grammar005.html#ctype_qualif
> +{unsigned char, unsigned short, unsigned int, unsigned long, unsigned long
> long, size_t, bool, u8, u16, u32, u64} vu;
How do you think about to reformat such a data type enumeration?
> +@@
> +
> +vu@p = vs
> +
> +@r@
> +position rs.p;
> +identifier v, f;
> +statement S1, S2;
> +expression e;
> +@@
> +
> +*v@p = f(...);
Do you try to check here if the value receiver is at the same source code
position from the SmPL rule "rs"?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
