Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cast from pointer to smaller type loses information #1314

Open
borogove opened this issue Apr 26, 2015 · 3 comments
Open

Cast from pointer to smaller type loses information #1314

borogove opened this issue Apr 26, 2015 · 3 comments
Labels

Comments

@borogove
Copy link

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants