-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/26/11 9:52 PM, Graham Cox wrote: > > On 27/05/2011, at 2:42 PM, Clark Cox wrote: > >> No. 'unsigned' is the same size on both 32- and 64-bit The only >> built-in types that are different between 32- and 64-bits are: >> >> signed long long (which is really the same as "signed long") >> unsigned long and any pointer type >> >> All other built-in types remain the same size between the two. > > > Thankyou - a definitive answer. I will print it out and frame it :)
This is also why you should probably use NSInteger/NSUInteger and CGFloat, where appropriate (though perhaps not here). They are typedef'd (in NSObjCRuntime.h/CGBase.h) on a per-architecture basis. > This suggest that Conrad's analysis is not quite right then, since > even if I'm overflowing the 32-bit integer, there's still enough > variation in what remains to give a valid and usable seed: > > 2011-05-27 14:25:14.689 Squaresgame[83159:a0f] seed: 276132753 > 2011-05-27 14:25:14.691 Squaresgame[83159:a0f] random: 1826068185 > 2011-05-27 14:49:36.081 Squaresgame[83217:a0f] seed: 290746671 > 2011-05-27 14:49:36.083 Squaresgame[83217:a0f] random: 162579918 Them are fightin' words. (Just kidding.) When I ran my sample code on my machine, I got constant results, not what you observed above. I would presume that long int is converted to unsigned int by chopping off the excess bits on the left, as you indicated, but my C implementation knowledge is too shallow to be certain. Don't know why I got the results I did. There is also the issue that I mentioned in my previous message: at least the documentation indicate that srandom() expects an unsigned int (NOT a long, or an NSUInteger, or something else). I'm frankly a little confused by this (and this is the first time I noticed that), but if that's the case, then who knows that srandom() is going to do internally if handed something wacky? (I do realize that you are declaring unsigned, so this presumably is not the problem in this case, but is something to be aware of.) I guess what I conclude from all this from this is: the fact that we are having this conversation indicates that you probably shouldn't be going this route. Even if the behavior you are seeing is the correct result (say, defined in the C spec), relying on these idiosyncrasies leads to potentially confusing and hard to read code. And if the behavior is NOT consistent (there are certainly plenty of type conversions out there that give "undefined result"), then the situation is even worse. As far as you current problem goes, though, it seems like more than enough people have chimed in with good approaches. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3fTocACgkQaOlrz5+0JdVpsgCfU9gXPDY+wpU8i2dSFNUo0cSS NvoAoIVKvXYmn9luGqetCvNhQFrX5+2x =t3tC -----END PGP SIGNATURE----- _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
