> In the example above spatch finds ull, ulli, but not ul and uli.
> If you add int to unsigned long long, it won't find anything.
I suggest to take another look at the use of type modifiers
in the semantic patch language. It seems that it matters occasionally
to specify them explicitly.
How do
On 09/22/2015 05:27 PM, SF Markus Elfring wrote:
>> If you mean adding int to 'unsigned long [long]' types, it does not work.
>> For some reason it works only without adding int after long.
> Do you get any error message for this SmPL approach?
> With which source files do you try the extended
> In the example above spatch finds ull, ulli, but not ul and uli.
> If you add int to unsigned long long, it won't find anything.
I suggest to take another look at the use of type modifiers
in the semantic patch language. It seems that it matters occasionally
to specify them explicitly.
How do
On 09/22/2015 05:27 PM, SF Markus Elfring wrote:
>> If you mean adding int to 'unsigned long [long]' types, it does not work.
>> For some reason it works only without adding int after long.
> Do you get any error message for this SmPL approach?
> With which source files do you try the extended
> If you mean adding int to 'unsigned long [long]' types, it does not work.
> For some reason it works only without adding int after long.
Do you get any error message for this SmPL approach?
With which source files do you try the extended SmPL script out?
Regards,
Markus
--
To unsubscribe from
> If you mean adding int to 'unsigned long [long]' types, it does not work.
> For some reason it works only without adding int after long.
Do you get any error message for this SmPL approach?
With which source files do you try the extended SmPL script out?
Regards,
Markus
--
To unsubscribe from
>> * Reuse of "long int"?
> If you mean adding int to 'unsigned long [long]' types, it does not work.
I am surprised.
> For some reason it works only without adding int after long.
The Coccinelle software should support the term "generic_ctype" from
the SmPL grammar so far, shouldn't it?
On 09/21/2015 03:02 PM, SF Markus Elfring wrote:
>> v3: added bool type
> I would appreciate a bit more feedback for my concerns around your
> evolving approach.
Ups, I have missed your email.
> * Reuse of "long int"?
If you mean adding int to 'unsigned long [long]' types, it does not work.
For
> v3: added bool type
I would appreciate a bit more feedback for my concerns around your
evolving approach.
* Reuse of "long int"?
* Splitting of the suggested SmPL rule so that each source code check
will be connected with appropriate warning messages.
Will any more fine-tuning be useful?
Code comparing unsigned variables with zero using operators < or >= does not
make sense. It is always false or true, respectively. However, its presence
often indicates bugs in the code.
gcc can detect it also using -Wtype-limits switch, but it warns also in correct
cases, making too much noise.
On 09/21/2015 03:02 PM, SF Markus Elfring wrote:
>> v3: added bool type
> I would appreciate a bit more feedback for my concerns around your
> evolving approach.
Ups, I have missed your email.
> * Reuse of "long int"?
If you mean adding int to 'unsigned long [long]' types, it does not work.
For
> v3: added bool type
I would appreciate a bit more feedback for my concerns around your
evolving approach.
* Reuse of "long int"?
* Splitting of the suggested SmPL rule so that each source code check
will be connected with appropriate warning messages.
Will any more fine-tuning be useful?
Code comparing unsigned variables with zero using operators < or >= does not
make sense. It is always false or true, respectively. However, its presence
often indicates bugs in the code.
gcc can detect it also using -Wtype-limits switch, but it warns also in correct
cases, making too much noise.
>> * Reuse of "long int"?
> If you mean adding int to 'unsigned long [long]' types, it does not work.
I am surprised.
> For some reason it works only without adding int after long.
The Coccinelle software should support the term "generic_ctype" from
the SmPL grammar so far, shouldn't it?
14 matches
Mail list logo