Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC:

Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 10:12 #24300

  • FdeRaadt
  • FdeRaadt's Avatar
  • Topic Author


  • Posts: 31
  • 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:
    Local i, n:=0 As Dword
    n += (Asc(SubStr(cContainernr,i,1))-55) * 2^(i-1)

    Whereas 2.12 requires this to run:
    Local i, n:=0 As Dword
    n += (Asc(SubStr(cContainernr,i,1))-55) * Dword(2^(i-1))

    Frank

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 10:45 #24301

    • robert
    • robert's Avatar


  • Posts: 3293
  • Frank,
    Your example does not show Int to dword conversions, I think.
    2^(i-1)
    This gets translated to the Math.Pow() method which returns a System.Double (Real8).

    Robert
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Last edit: by robert.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 11:04 #24302

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • 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

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 11:07 #24303

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • 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

    Please Log in or Create an account to join the conversation.

    Last edit: by ic2.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 11:27 #24304

    • FFF
    • FFF's Avatar


  • Posts: 1393
  • 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...
    Regards
    Karl (X# 2.14.0.4; Xide 1.33; W8.1/64 German)

    Please Log in or Create an account to join the conversation.

    Last edit: by FFF.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 12:02 #24307

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • 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

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 12:07 #24308

    • Chris
    • Chris's Avatar


  • Posts: 3759
  • 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.

    #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
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 14:26 #24309

    • robert
    • robert's Avatar


  • Posts: 3293
  • 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
    XSharp Development Team
    The Netherlands

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 14:51 #24310

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • 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

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 16:14 #24312

    • Chris
    • Chris's Avatar


  • Posts: 3759
  • 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.
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 01 Nov 2022 17:59 #24314

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • Hello Chris,

    Which compiler error was removed?

    What I meant is not that the error was totally removed, but that there were several cases in which it appeared in 2.12 (and should appear IMO) and not in 2.13.

    Apart from the 2 I wrote above:

    nInt := longint(nFrac*10000)

    I had to add longint . nFrac is a float and nInt is a LongInt

    Next sample:
    ACCESS LineSize()	AS BYTE STRICT CLASS IVFile
    RETURN [b]byte[/b](SELF:dwMaxbytes)

    Self:dwMaxbytes is a DWORD. As the access is defined "as byte strict" it makes more sense to me that 2.12 gives a compiler error (before adding the bold "byte") than that 2.13 does not.

    IF SELF:oTargetFile:OpenFile(strFileName,word(dwOpenMode))

    Here I had to add the (bold) word in order to get it compiled, but only in 2.12. The second parameter of OpenFile is defined as word. So again it doesn't make sense to me that 2.13 accepts a DWORD parameter dwOpenMode.

    There are a few more errors we could solve in 2.12 but I think it gives you an idea.

    Dick

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 02 Nov 2022 00:03 #24317

    • Chris
    • Chris's Avatar


  • Posts: 3759
  • Hi Dick,

    When I try your first sample with nFrac, I get a compiler error as expected:

    error XS0266: Cannot implicitly convert type 'float' to 'int'. An explicit conversion exists (are you missing a cast?)

    When I try the second sample, with the byte, I get a compiler error again:

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

    So I am not seeing what you are saying. Maybe you can create and post a full sample reproducing the problem?

    .
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 02 Nov 2022 10:18 #24319

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • Hello Chris,

    I will ask Frank what he can do.

    What we did: Frank had a 100 % compiling solution (using the latest X# 2.13) which he cloned for me so I could read it read it via Git as a new solution. When I compiled that very same solution (in X# 2.12) I got about 2 dozen of compiler errors, as mentioned.

    After Frank re-installed 2.12 he got the same errors and could solve them.

    So something apparently didn't work as it should.

    Dick

    Please Log in or Create an account to join the conversation.

    Last edit: by ic2.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 02 Nov 2022 13:49 #24320

    • Chris
    • Chris's Avatar


  • Posts: 3759
  • Hi Dick,

    OK, understood. If you can create a sample showing this problem, we will have another close look into it.

    .
    XSharp Development Team
    chris(at)xsharp.eu

    Please Log in or Create an account to join the conversation.

    Conversion from 'int' to 'dword' may lead to loss of data or overflow errors 03 Nov 2022 13:12 #24329

    • ic2
    • ic2's Avatar


  • Posts: 1574
  • Hello Chris,

    OK, understood. If you can create a sample showing this problem, we will have another close look into it.
    .

    We think we can't provide you anymore with the cloned project which compiled in 2.13x and revealed it's errors only in 2.12 because Frank issued a few more commits in the meantime.

    It's difficult to say why about 20 errors definitely did not pop up in 2.13. We had this sometimes in VO, e.g. when one of us got a new repo copy with a resource (which worked) but only once the repo was touched it could e.g. detect a missing source icon or something.

    Hence I thought that these faulty lines did not yield compiler errors in 2.13, but as you did get the compiler errors in 2.13 I can't think of another cause. But it did happen like I wrote for sure.

    For us personally it's no longer a problem as we both returned to X# 2.12.

    Dick

    Please Log in or Create an account to join the conversation.

    • Page:
    • 1