Why is I2H unsafe?

06-18-2008, 05:03 PM	#1
Ragnarok X	I have been reading all the existing bugs on Jass again. To my surprise, i heard about I2H usafety. I tried to find info about it, but i can't find any. Can someone explain me, WHY are I2H or similars unsafe?

06-18-2008, 05:48 PM	#2
Anitarf	Nobody knows. It's merely a suspicion based on maps having less visible bugs after I2H is no longer used in them. That, along with the fact that with vJass structs, I2H is no longer needed, is sufficient cause to not use I2H anymore.

06-18-2008, 06:03 PM	#3
darkwulfv	What used I2H anyways? And what was it used for? (I don't think it was Handle Vars, because I've looked and it only seems to use H2I, not I2H. Could be wrong though)

06-18-2008, 06:05 PM	#4
Squally425	My random guess would be... While many natives takes a specific child of handle, not many actually take handles. If you coded your own function to accept a handle, theres a chance that the integer converted to handle isn't used properly and crash the map? For example, an integer of a timer sent to a function that tries to use it like a unit? Just a wild guess.

06-18-2008, 06:32 PM	#5
Captain Griffen	I2H could give a handle of a different type to what you believe or no type, in which case bad shit happens. It's also far more vulnerable to handle stack corruption (or voodoo).

06-18-2008, 06:50 PM

Themerion

Quote:

Originally Posted by Wolfy

What used I2H anyways? And what was it used for? (I don't think it was Handle Vars, because I've looked and it only seems to use H2I, not I2H. Could be wrong though)

I2H is how you generally refer to any function which converts an object ID into a handle subclass.

GetHandleUnit:

 // Returns GetStoredInteger as a unit
// Integer -> Unit
// (unit is a subclass of handle)
// Integer -> Handle
// I2H

function GetHandleUnit takes handle h, string key returns unit
    return GetStoredInteger(udg_cache,I2S(H2I(u)),key)
    return null
endfunction

Quote:

Originally Posted by Ragnarok X

Can someone explain me, WHY are I2H or similars unsafe?

Warcraft internally keeps track on how many variables are pointing towards an object's ID. When the object is destroyed, and no more variables refer to the object, the object's ID is recycled.

If you use an integer for refering to an object, and that object is destroyed, the object's ID will get recycled. Then another object might get that very id (since it's recycled). Thus, your integer are now pointing at the other object.

JASS:

function DoAtInitInAMapWhichDoesNotCreateNewObjects takes nothing returns nothing
    local trigger trg=CreateTrigger()
    local integer i=H2I(trg)
    call DestroyTrigger(trg)
    set trg=null
 // The handle id is recycled...
    call CreateGroup()
 // This group may now have the same id as the trigger...
    call PauseTrigger(I2Trigger(i))
 // Congratulations. You have paused a unit group :P
endfunction

This is obviously a serious problem, since the second object might be of a totally different type than the first one. You might for instance end up telling Warcraft to do KillUnit on a trigger...

06-18-2008, 07:40 PM	#7
TheDamien	Not as serious as you might expect. You can call KillUnit on a trigger without serious error - natives seem to check the type. IIRC the major bug was that I2Hing an ID that was not in use caused handle stack corruption.

06-18-2008, 07:51 PM	#8
Ragnarok X	Thx guys. Then it is safe to use I2H functions if i can delete every pointer to a being destroyer object. I really thought it was much worse.

06-18-2008, 07:56 PM	#9
Squally425	Hehe in programming, every small little problem is usually treated as a gigantic problem because as programs grow in size, those little problems blend in and eventually creates an outrage. Which is why its better to avoid doing it altogether. A good example is the good old Goto. Goto is harmless, until you use it sooo much that after awhile debugging becomes impossible. :D

06-18-2008, 08:00 PM	#10
Here-b-Trollz	You're much better off just not using I2H, because that usually implies gamecache, which means that your inputs and outputs aren't as black and white as you'd like (strings aren't near as robust as integers). So, unless you're on a mac, you'll want to use some vJass and avoid unnecessary gamecaching.

06-18-2008, 08:01 PM

#11

Vexorian

Quote:

Then it is safe to use I2H function

No, it is never safe (or necessary) to use that stuff. Remember, never. A direct way to break stuff is to use I2H on dead things, but it is not the only way. I2H loves to mess up the reference counter.

Quote:

Nobody knows.

Pipe does. However I was unable to get the explanation ...

Squally425: I2H is much worse than goto, your stuff won't break automatically for using goto...

06-18-2008, 08:10 PM

#12

Rising_Dusk

Quote:

Originally Posted by Vexorian

This is totally correct. Take it from me, a person whose map has been desecrated by shit like I2H, never, ever use it! There are always better solutions.

06-18-2008, 09:06 PM

#13

Themerion

I have no idea why you want to use I2H, but you should really use CSData for attaching to private objects (part of Vexorian's Caster System), and Cohadar's PUI for "attaching" to units. I2H is just stupid, considering that the methods above are both much more safe and faster.

Both the Caster System and PUI are available in the resources section.
Resources -> Demo Maps -> Systems

EDIT: I misplaced a H and an I. Fixed.
Ofc H2I isn't stupid. CSData, HSAS, HAIL, and ABC all use H2I :P Well, good ol' CSCache and handle vars too (though they use I2H as well, which makes them... evil :)

06-18-2008, 09:08 PM

#14

Captain Griffen

Quote:

Originally Posted by Themerion

H2I used properly is fine, and often used in combination with systems like CSData.

I2H is dangerous and completely unnecessary.

06-18-2008, 09:14 PM	#15
Rising_Dusk	H2I is still extremely useful, it's I2H that's the bugger.