Re: [Vala] Trap for the unwary or incorrect code?

[Andy Lees <andrewl oz gmail com>]

Ah yes, my bad, my original code had the unsigned operand as explicitly 32
bits, which I had expected to up-cast to int.  But in fact ints aren't
wider even with a 64 bit architecture.  Strict type checking as an option
for all type in all uses would be a helpful bug squishing tool.

On Sun, May 22, 2016 at 12:56 AM, Al Thomas <astavale yahoo co uk> wrote:

> ----- Original Message -----
> > From: Andy Lees <andrewl oz gmail com>
> > Sent: Saturday, 21 May 2016, 14:56
> > Subject: [Vala] Trap for the unwary or incorrect code?
> >
> > If I have the following code, or similar:
> > void main (string[] args) {
> >   uint ui = 2;
> >   int i = -3;
> >   if (i < ui) {
> >     stdout.printf("Comparison works\n");
> >   }
> > }
> >
> > No output is produced.  Given Vala is generally very good at warning
> about
> > type mismatches, or correctly doing an implicit cast, I find this rather
> > strange.  Yes, I should not be comparing a negative value against an
> > unsigned value, but logically the comparison should produce the expected
>
> > output, I would have thought?
> > > In general, as type inference can make the type of a variable unclear
> to
> > the casual viewer, and the declaration of a variable may be in a
> different
> > file, this permissiveness is a potential source of error, I think.
>
>
>
> At present I would say this is a trap for the unwary, although a
>
> --strict-value-type mode for Vala may be helpful. This is a well known
> problem
> in the C world.
>
> In Vala the spec for relational arithmetic operators says "Where both
> operands
>
> are of integer type, both are converted to the largest integer type
> involved"
>
> https://wiki.gnome.org/Projects/Vala/Manual/Expressions#Relational_operations
> Presumably that means the largest value rather than range of values.
>
> You will also find this with arithmetic operations, e.g.
>
>
> http://stackoverflow.com/questions/35305625/vala-quotient-of-two-integers-is-always-an-integer-why
>
> In C this type of behaviour is labelled the "usual arithmetic conversions"
> if
> you want to do a search. Some examples showing what you have found:
>
> https://www.securecoding.cert.org/confluence/display/c/INT02-C.+Understand+integer+conversion+rules
>
> http://www.iesensor.com/blog/2012/10/21/unsigned-integer-can-be-evil-c-implicit-conversion/
>
> Al