>> +{unsigned char, unsigned short int, unsigned int, unsigned long, unsigned
>> long long, size_t, u8, u16, u32, u64} v;
How about adding bool? I don't currently find any problems with it, but
perhaps some could arise.
julia
> >> +@@
> >> +
> >> +(
> >> +*v@p < 0
> >> +|
> >> +*v@p >= 0
>
On Wed, 16 Sep 2015, Andrzej Hajda wrote:
> On 09/15/2015 03:57 PM, Julia Lawall wrote:
> >
> >
> > On Tue, 15 Sep 2015, Andrzej Hajda wrote:
> >
> >> On 09/15/2015 03:31 PM, Julia Lawall wrote:
> >>> On Tue, 15 Sep 2015, SF Markus Elfring wrote:
> >>>
> >> v@p
> >> (
> >> *< 0
> >>
On 09/15/2015 03:57 PM, Julia Lawall wrote:
>
>
> On Tue, 15 Sep 2015, Andrzej Hajda wrote:
>
>> On 09/15/2015 03:31 PM, Julia Lawall wrote:
>>> On Tue, 15 Sep 2015, SF Markus Elfring wrote:
>>>
>> v@p
>> (
>> *< 0
>> |
>> *<= 0
>> )
> It does not, and is not intende
> --recursive-includes is already a parameter.
I am unsure if its effect on source code analysis speed will matter here.
> size_t is also unsigned.
Will such a specification work also without an explicit SmPL typedef?
Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, 15 Sep 2015, SF Markus Elfring wrote:
> > If you think about removing all u* typedefs
>
> I became interested in the use case to consider more type definitions
> besides the ones which should usually be handled for Linux source files.
>
>
> > it will result in omitting u* related compariso
> If you think about removing all u* typedefs
I became interested in the use case to consider more type definitions
besides the ones which should usually be handled for Linux source files.
> it will result in omitting u* related comparisons,
> unless you use --recursive-includes option.
How do
On Tue, 15 Sep 2015, Andrzej Hajda wrote:
> On 09/15/2015 03:31 PM, Julia Lawall wrote:
> > On Tue, 15 Sep 2015, SF Markus Elfring wrote:
> >
> v@p
> (
> *< 0
> |
> *<= 0
> )
> >>> It does not, and is not intended to, work. The branches of a disjunction
> >>> shou
On 09/15/2015 03:31 PM, Julia Lawall wrote:
> On Tue, 15 Sep 2015, SF Markus Elfring wrote:
>
v@p
(
*< 0
|
*<= 0
)
>>> It does not, and is not intended to, work. The branches of a disjunction
>>> should be complete expressions.
>> Will the following SmPL approach be
On 09/15/2015 03:01 PM, SF Markus Elfring wrote:
>> +@r depends on context || org || report@
>> +position p;
>> +typedef u8, u16, u32, u64;
> Can the involved data types be restricted for unsigned types for such
> a source code analysis in a more general way?
I am not sure if I understand correctl
On Tue, 15 Sep 2015, SF Markus Elfring wrote:
> >> v@p
> >> (
> >> *< 0
> >> |
> >> *<= 0
> >> )
> >
> > It does not, and is not intended to, work. The branches of a disjunction
> > should be complete expressions.
>
> Will the following SmPL approach be more appropriate then?
>
> (
> *v@p < 0
>
>> v@p
>> (
>> *< 0
>> |
>> *<= 0
>> )
>
> It does not, and is not intended to, work. The branches of a disjunction
> should be complete expressions.
Will the following SmPL approach be more appropriate then?
(
*v@p < 0
|
*v@p <= 0
)
Regards,
Markus
--
To unsubscribe from this list: send the
On Tue, 15 Sep 2015, SF Markus Elfring wrote:
> > +@r depends on context || org || report@
> > +position p;
> > +typedef u8, u16, u32, u64;
>
> Can the involved data types be restricted for unsigned types for such
> a source code analysis in a more general way?
>
>
> > +{unsigned char, unsigned
> +@r depends on context || org || report@
> +position p;
> +typedef u8, u16, u32, u64;
Can the involved data types be restricted for unsigned types for such
a source code analysis in a more general way?
> +{unsigned char, unsigned short int, unsigned int, unsigned long, unsigned
> long long, s
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.
S
14 matches
Mail list logo
