Cast from pointer to smaller type loses information

[borogove]

Cocos2d-spritebuilder 3.4.3.

In CCTMXXMLParser.m, line 500:

inflatedLen = (int)&inflatedLen; // XXX: to avoid warings in compiler

This looks like a pretty shady suppression of an unused variable warning (casting to void is preferable).

I'm building an Objective-C++ project, which seems to have different casting rules, so this is a fatal compilation error: Cast from pointer to smaller type 'int' loses information

There are a number of other casting errors across the codebase in Objective-C++ mode. This thread from October 2014 toyed with the idea of adding Objective-C++ source to the tests: http://forum.cocos2d-spritebuilder.org/t/cocos3d-c-mm-files-compiler-issue/15570/3

[slembcke]

O_o Yeah, that is pretty bad. To be honest, I touch the tile map code as little as possible. It's really fragile with lots of unsafe implementation details exposed in the public headers and a lot of problems with content scales lurking around in it. In v3, the only thing I did was update the rendering routines so it didn't try to keep all of the vertex data in memory and render it all every frame.

I cleaned it up a bunch in the v4 development branch. Removing a few of the dangerous or questionable public APIs. I know that line you posted has to do with the old zlib decompression code. That was actually completely replaced by streaming decompression in the new CCFile class. Less code, simpler API, and much more flexible.

Though... now that I think about it. Why are you compiling the existing .m files as Objective-C++? I'm surprised you don't find a lot more issues.

[borogove]

I'm finding a ton of issues, yeah.

I switched it into "everything is O-C++" mode to try and deal with other problems in my (old, cocos 2.x) codebase - let me try going back to "by file type" and see if I can clear those up another way.

[Birkemose]

Hmmm ... while it certainly is bad programming practice, the analyser doesn't choke on it, so I guess it is safe.