PDA

View Full Version : Strange Compiler Error



ywkls
06-29-2017, 10:24 PM
So, I was attempting to compile a script today which included this line...


if(Link->CollDetection==true)

This gave me an error... Cannot cast from bool to float. (I don't remember the precise number of said error.)
I should note that this didn't occur on every instance where I had this in the script. Possibly because of the way that the parser examines things? I don't know.

Changing it to this worked...


if(Link->CollDetection)

Since as far as I know, most bools accept the syntax in the first section of code, I'm pretty sure the fact this doesn't is a bug.

Saffith
06-29-2017, 10:31 PM
Huh. Yep, getCollDetection returns TYPE_FLOAT, and it's not the only one. Changing that shouldn't cause any problems, I don't think.

ZoriaRPG
06-30-2017, 09:05 AM
Huh. Yep, getCollDetection returns TYPE_FLOAT, and it's not the only one. Changing that shouldn't cause any problems, I don't think.

Nah, I fixed it for 2.55/2.60, and I will apply the same fix in 2.53. I knew what it was as soon as ywkls reported it on Skype, but I wanted him to post it here as a reminder for me.

For the record, this affected CollDetection for lweapon, eweapon, and npc; but none of the other vars, or functions seem to have an incorrect return type at this time. My apologies if this created extra work for you Saffith. I merely needed a reminder, and I asked ywkls to post it in the dev chat. I didn't expect him to submit a full bug report, although it was nice of him to do that.

Update: Fixed for 2.53/2.50.2.1.sheep, too.

P.S. ywkls: if ( ptr->CollDetection ) only worked because float is typecast to bool in that type of statement. When there is an explicit COMPARE to a boolean type (true/false), the proper bool return is mandatory. -- Clearly, no-one had ever tried if ( ptr->CollDetection = true ) in the past ???.

Saffith
06-30-2017, 12:19 PM
Link->Invisible needs it, too. I think that's the only other one.
Shouldn't this be corrected in the repo before it's marked as fixed?

ywkls
06-30-2017, 01:20 PM
P.S. ywkls: if ( ptr->CollDetection ) only worked because float is typecast to bool in that type of statement. When there is an explicit COMPARE to a boolean type (true/false), the proper bool return is mandatory. -- Clearly, no-one had ever tried if ( ptr->CollDetection = true ) in the past ???.

It does seem odd to me that this has never turned up before, but I figured it would be an easy fix.

I'm guessing that the setters were all correct, otherwise they'd have complained long hence. There's no telling why the getters were wrong.

ZoriaRPG
07-01-2017, 05:01 AM
Link->Invisible needs it, too. I think that's the only other one.
Shouldn't this be corrected in the repo before it's marked as fixed?

It is corrected in the stuff that I have staged to merge. DarkDragon asked not to make any new commits until he finishes his internal changes. I can put the 2.50.2.1 source up separately if you want, but I do not have access to dump it to GH/AGN.

Here is the revision for this fix for master:

https://github.com/ZoriaRPG/ZeldaClassic/compare/23_SpriteData...ZoriaRPG:24_Fix_CollDetection_Retu rn?expand=1

I thought that marking a bug as 'sick' was the appropriate middle-ground between implementing the fix, and verifying that it was fixed in use?

Here is the 2.50.2.1 code: https://github.com/ZoriaRPG/ZeldaClassic_2.53

Edit: I re-applied the changes to the 2.50.x branch:
https://github.com/ArmageddonGames/ZeldaClassic/compare/2.50.x...ZoriaRPG:2.50.x

Let's hope that I did not overlook anything, and that this compiles properly.


It does seem odd to me that this has never turned up before, but I figured it would be an easy fix.

I'm guessing that the setters were all correct, otherwise they'd have complained long hence. There's no telling why the getters were wrong.

Aye. The setters are fine, and as I said, i suspect it is because the syntax if ( Link->CollDetection ) or if ( Link->Invisible ) is cleaner, or easier to type, and read; as compared to if ( foo == true ) . It is also less error-prone, as you cannot have an assign here where you intend a compare, when doing a simple boolean evaluation, so fewer people use == true in these cases.

Similarly, most users will do if ( !foo ) rather than if ( foo == false ). I would still have expected it to be reported before, but the userbase is clearly not reporting issues when they should, and they try to find hacks, or workarounds to the, rather than alerting us fix them.

Internally all of these values are integers. Only the ZScript parser distinguishes between float, and bool; or other types.