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

This forum is meant for questions and discussions about the X# language and tools
ic2
Posts: 1818
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

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

Post by ic2 »

Hello Chris,
Chris post=24312 userid=313 wrote: 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:

Code: Select all

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
User avatar
Chris
Posts: 4616
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

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

Post by Chris »

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?

.
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
ic2
Posts: 1818
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

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

Post by ic2 »

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
User avatar
Chris
Posts: 4616
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

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

Post by Chris »

Hi Dick,

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

.
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
ic2
Posts: 1818
Joined: Sun Feb 28, 2016 11:30 pm
Location: Holland

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

Post by ic2 »

Hello Chris,
Chris post=24320 userid=313 wrote: 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
Post Reply