Conversion from 'int' to 'dword' may lead to loss of data or overflow errors

[FdeRaadt]

Hello Everyone,

I've noticed from Whatsnew Changes in 2.13.0.7:

Compiler New Features
We have revised the behavior of the /vo4 and /vo11 command line options that are related to numeric conversions.

Meaning that Int to Dword conversions no longer lead to Compiler Errors but are added to the warnings list instead.
I've noticed this change because I've also tried to recompile my application with X# 2.12.0.0

I think this change is quite odd.
In my opinion the compiler should grow more strict over time.
The compiler in 2.13.0.7 currently ignores these conversion errors.

A sample would be:

This leads to no Compiler errors in 2.13.0.7:

Code: Select all

Local i, n:=0 As Dword
n += (Asc(SubStr(cContainernr,i,1))-55) * 2^(i-1)

Whereas 2.12 requires this to run:

Code: Select all

Local i, n:=0 As Dword
n += (Asc(SubStr(cContainernr,i,1))-55) * Dword(2^(i-1))

Frank

[robert]

Frank,
Your example does not show Int to dword conversions, I think.

Code: Select all

2^(i-1)

This gets translated to the Math.Pow() method which returns a System.Double (Real8).

Robert

[ic2]

To add something to this:

We cloned Frank's project in my system. Frank is using some X# 2.13 version while I reverted to 2.12. When I compiled the project I got at least a dozen XS0266 errors. Here's another one:

nVolgnr := oDBOmschrijf:saldo + 1

nVolgnr is a DWORD and saldo is a float.

This all compiled in 2.13. Frank is will most likely revert to 2.122 as well, otherwise he needs me to fix the errors. After I solve a couple of errors I get an about equal number of new ones (of the same kind, like this XS0266.

Is there something he can change to actually see these errors or should he revert to 2.12 too?

Dick

[ic2]

This gets translated to the Math.Pow() method which returns a System.Double (Real8).

Right. So a Real8 value is multiplied with a DWORD value (Asc(...) and 2.12 this gives

Error XS0266 Cannot implicitly convert type 'real8' to 'dword'. An explicit conversion exists (are you missing a cast?)

and 2.13 has no problem with it.

Dick

[FFF]

Guys,
the TE uses 2.13.0.7 - the actual build is 13.2.2
Before entering in debates about different POV how to handle disputable decisions, i'd suggest moving forward...

[ic2]

Hello Karl,

Before entering in debates about different POV how to handle disputable decisions, i'd suggest moving forward...

You mean moving forward to a version which allows all kind of implicit conversions? Because Frank used the latest version and fixed the errors by also reverting to 2.12 like I did weeks ago.

I am not seeking a debate. We simply wanted to know why 2.12 gives a compiler error on different types (which I think the compiler should do) and 2.13 does not, with the same settings. Frank suggested that he expects the compiler to become more strict over versions and not the other way around, which seems the case here. Where am I wrong in this conclusion?

Dick

[Chris]

Guys,

Indeed there's a small issue here, especially with the "^" operator. As the sample code below shows, when the /vo4 compiler option (allow implicit numeric vonversions) is enabled, then both using a^b and Pow(a,b) produce a narrowing conversion warning which is correct. When this option is disabled, then using Pow() now produces a compiler error which is correct, but using the ^ operator instead does not report one, which is a bug. Will log this for Robert to fix it.

Code: Select all

#pragma options ("vo4", on)
FUNCTION Test_vo4_on() AS VOID
LOCAL dw AS DWORD
LOCAL n := 2 AS DWORD
dw := n + Pow(n,n) // warning XS9020
? dw
dw := n + n^n // warning XS9020
? dw


#pragma options ("vo4", off)
FUNCTION Test_vo4_off() AS VOID
LOCAL dw AS DWORD
LOCAL n := 2 AS DWORD
dw := n + Pow(n,n) // error XS0266
? dw
dw := n + n^n // no error, wrong
? dw

[robert]

Dick,

I am not seeking a debate. We simply wanted to know why 2.12 gives a compiler error on different types (which I think the compiler should do) and 2.13 does not, with the same settings. Frank suggested that he expects the compiler to become more strict over versions and not the other way around, which seems the case here. Where am I wrong in this conclusion?

It is a bit too simplistic to always expect newer version to be stricter than older versions.
We also make changes to make newer versions more compatible with the "old" products VO, FoxPro etc.
Sometimes that means that a newer version is less strict.

Robert

[ic2]

We also make changes to make newer versions more compatible with the "old" products VO, FoxPro etc.
Sometimes that means that a newer version is less strict.

Apparently again something I misunderstood; I thought that compatibility was, so far, achieved with the switches (from which we also use a few), not by removing (I'd say technically correct) compiler errors over the versions. That means that to ensure these errors are actually known a copy of 2.12 should always remain somewhere on your Pc. In other words: 2.12 makes you more aware that you need to cast a part of your code and in theory affect the outcome, or adapt the code. It is of course, so far, fast & easy to quickly go back to 2.12 if you want to use later versions, fix the compiler errors, and reinstall a new version, as it will often only happen with converted code.

@Chris: Thanks for confirming that specific issue.

Dick

[Chris]

Dick,

Which compiler error was removed? I don't see any. Only thing I see is that specific problem with the ^ operator in particular, which by accident does not trigger the intended error, but apart from that, there's always a compiler error for incompatible numeric conversions, unless /vo4 is used. If you do see another such case, it must also be by accident, please give us a sample showing it and it will also be taken care of.