The video "Gangnam Style " has broken the view limit in YouTube, prompting an update into how views are handled.
The music video for South Korean singer Psy's Gangnam Style exceeded YouTube's view limit, prompting the site to upgrade its counter.
YouTube said the video - its most watched ever - has been viewed more than 2,147,483,647 times. It has now changed the maximum view limit to 9,223,372,036,854,775,808, or more than nine quintillion.
This discussion has been archived.
No new comments can be posted.
Gangnam Style Reaches YouTube View Limit
|
Log In/Create an Account
| Top
| 67 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 2) by ikanreed on Thursday December 04 2014, @09:49PM
#103 View counter causing an overflow error
(#4 Waiting 3 seconds for a free international music video to load)
(Score: 3, Interesting) by MrGuy on Thursday December 04 2014, @09:57PM
To be fair, imagining being so popular that 1/3rd of the earth's population watched a single video would have been a pretty progressive idea.
(Score: 2) by Tork on Thursday December 04 2014, @10:01PM
To be fair, imagining being so popular that 1/3rd of the earth's population watched a single video would have been a pretty progressive idea.
That number does not represent individual viewers.
Slashdolt Logic: "25 year old jokes about sharks and lasers are +5, Funny." 💩
(Score: 0, Troll) by Ethanol-fueled on Thursday December 04 2014, @10:05PM
Instead of having all these messy wars, we could depopulate the world deciding who to euthanize using that single metric.
It would be more efficient than the bureaucracies behind a thousand holocausts!
(Score: 2) by bob_super on Thursday December 04 2014, @10:07PM
Considering what passes for "music" these days, it could have been worse.
Now get off my lawn!
(Score: 2) by Tork on Thursday December 04 2014, @10:47PM
Slashdolt Logic: "25 year old jokes about sharks and lasers are +5, Funny." 💩
(Score: 1) by Pete (big-pete) on Friday December 05 2014, @08:33AM
Exactly what is your problem about this video (out of all videos) being popular?
Would you have preferred the YouTube breaking video to be some dross churned out by the American music machine, do you have a problem with a (previously mostly-unknown outside of Asia) Korean guy making fun of pretentious over privileged people whilst clearly not taking himself seriously to a fun beat and an amusing backdrop? Maybe you're a Belieber?
Perhaps you long for the days when "Charlie bit my finger" was the absolute mutts nuts when it came to YouTube viewing?
Or maybe you just hate on it because it's popular, and hur hur, whatever is popular must be beneath you?
-- Pete.
(Score: 1) by Ethanol-fueled on Friday December 05 2014, @02:50PM
My beef with the song is that it sounds goddamn obnoxious.
It uses raucous buzzy distorty sawtooth synths with an ad-hoc atonal "melody" consisting of tritones under a pounding beat, all of which having the overall effect of a crippling Fireball hangover while coming down from meth.
Yeah, no. "Fun beat," my ass. You must be on a lot of molly to call that a "fun beat." One day you'll understand when you ditch the pacifier, pink leg-warmers, and neon necklaces and realize that must electronic music sucks.
(Score: 2) by Joe Desertrat on Saturday December 06 2014, @07:51PM
That number does not represent individual viewers.
Who would watch it more than once?
(Score: 2) by Tork on Saturday December 06 2014, @10:41PM
Slashdolt Logic: "25 year old jokes about sharks and lasers are +5, Funny." 💩
(Score: 2) by FatPhil on Friday December 05 2014, @01:01PM
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 2) by cykros on Friday December 05 2014, @01:51PM
Yea, but now that it's 2014, rather than talking about small potatoes like the Beatles or Jesus, we have Psy to show us what popularity really is.
On another tack though; has nobody considered that he may secretly be an operative of the DPRK and that this is the beginning of their cyberattack campaign on our infrastructure? Hitting us in the cat videos would probably be the single most disruptive attack I can think of anyway...
(Score: 4, Interesting) by steveha on Thursday December 04 2014, @09:50PM
On the YouTube page for the Gagnam Style video [youtube.com]: when you hover the mouse pointer over the views count, YouTube shows an animation of crazy numbers spinning, as if the video were being watched so many times that YouTube can't update the counter fast enough.
Amusing for a second.
(Score: 2) by FakeBeldin on Thursday December 04 2014, @10:28PM
And it then displays what the counter would say if it were still a 32-bit integer, instead of a 64 bit.
(Score: 3, Interesting) by cafebabe on Saturday December 06 2014, @09:14PM
I presume that a spinning counter is a jokey stopgap because doing (the equivalent of) ALTER TABLE or ALTER COLUMN is awkward on a frequently updated database table. Especially so if it is a distributed database such as Google's BigTable. The traditional workaround to keep summary tables consistent is to use triggers. BigTable now supports triggers but the sheer volume would make deployment untenable.
Obvious migration techniques won't work because a large, frequently updated, distributed database requires a fix which does not double database load. Creating a temporary table with a BIGINT SIGNED column and incrementing those values from zero doesn't work. In this scenario, reading the number of hits requires two accesses and that creates significant load. Creating a temporary overflow flag table for IDs approaching the 31 bit limit doesn't work either because that also requires two accesses.
It is possible to temporarily hard-code a Bloom filter [wikipedia.org] of IDs approaching the INT SIGNED limit. This should keep additional load under 1% and allow the summary column to be migrated to a BIGINT SIGNED without the instance of BigTable collapsing under additional load.
However this gets fixed, don't expect it to occur promptly because a migration plan will require extensive meetings.
1702845791×2
(Score: 2) by francois.barbier on Thursday December 04 2014, @09:58PM
That's another overflow waiting to happen! The fools!!!
On a more serious note, I wonder how do you store such a number?
(Score: 2) by bob_super on Thursday December 04 2014, @10:05PM
Since this is a geeky place, TFS should have been "Gangnam Style risks overflowing 32-bit signed int YouTube view counter. Changed to 64-bit signed int"
Still fits in 640k of RAM, though.
(Score: 2) by nitehawk214 on Thursday December 04 2014, @10:24PM
Why signed?
"Don't you ever miss the days when you used to be nostalgic?" -Loiosh
(Score: 3, Interesting) by steveha on Thursday December 04 2014, @10:37PM
Why signed?
The article doesn't say.
Very possibly it's because the YouTube web site runs on Java, which doesn't offer unsigned integers [stackoverflow.com].
It could also be that YouTube uses a database that offers only signed integers. (Presumably YouTube uses Google BigTable [wikipedia.org] but I don't know much about BigTable.)
(Score: 1) by Nait on Friday December 05 2014, @02:11PM
AFAIK YouTube is written in Python not Java. [1]
Also they probably used signed int, because using unsigned int is against their guidelines[2]
1. http://highscalability.com/youtube-architecture [highscalability.com]
2. https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types [googlecode.com] (although it cpp guide, but I assume that they are consistent with this)
(Score: 1) by steveha on Friday December 05 2014, @05:43PM
Python doesn't have unsigned integers. Also Python integers can't overflow... in Python 2.x if an integer expression would overflow it promotes to "long integer" which is a bignum type, and in Python 3.x there is only one integer type and it is a bignum type.
So if they really don't use Java, the most likely explanation for this even being an issue at all is that their database stores signed fixed-length integers.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @12:00AM
This is a consequence of how numbers are physically represented in hardware. Any number is a combination of bits (2-digit numbers, ie 1s and 0s). I won't bore you with the mathematics, but essentially, this means that you can only store up to 2^n unique combinations per n bits (^=power of). Unsigned integers simply take this value to mean a positive number, where as signed integers interpret the first half of the combinations as negative, and the 2nd as positive.
The reason 32-bit and 64-bit are commonly used is because processors usually have special instructions to operate on numbers equal to their address length, which makes them extremely fast.
Note, that this only applies to integers. Real numbers are a lot more complicated.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @11:38AM
Well, the question was why they didn't take the interpretation that only gives positive numbers, given that the number of views never can be negative anyway. I'm pretty sure the poster already knew how numbers are represented in computers.
Of course the other reply already gave a reasonable answer to the question.
(Score: 2) by MrNemesis on Friday December 05 2014, @12:15PM
You've watched it - but with enough liquor and therapy you can unwatch it.
"To paraphrase Nietzsche, I have looked into the abyss and been sick in it."
(Score: 2) by MrGuy on Thursday December 04 2014, @10:08PM
Ones and zeros, man. Ones and zeros.
(Score: 2) by rts008 on Thursday December 04 2014, @11:23PM
I recommend Fort Knox...I hear there is room there now. ;-)
(Score: 0) by Anonymous Coward on Thursday December 04 2014, @11:41PM
libgmp
https://gmplib.org/ [gmplib.org]
(Score: 0) by Anonymous Coward on Friday December 05 2014, @12:15AM
The number of combinations you can represent in a set of n bits is 2 to the power of n. As all exponential functions, this gets very ridiculous very fast. 128bit signed numbers can represent numbers with 38 significant digits, and 256bit numbers can represent as much as 80. For comparison, 10^80 is about how many atoms there are in the universe according to our estimations (give or take a few orders of magnitude, this isn't exactly precise science).
(Score: 1) by Pseudonymous Coward on Friday December 05 2014, @04:58AM
A signed 64 bit integer.
Why did they use a signed one? Did they HAVE to have support for *negative* views?
Why not an unsigned one?
(Score: 2) by Thexalon on Friday December 05 2014, @02:53PM
Yes, for all those who wanted to unwatch Rick Astley's "Never Gonna Give You Up" or Justin Bieber's "Baby".
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Insightful) by soylentsandor on Friday December 05 2014, @03:52PM
As mentioned in a comment somewhere above, their guidelines say to always use signed. I can imagine mixing signed and unsigned opens up a can of worms, depending on environment. It's better to stick with always signed then.
Besides, unsigned would have bought them maybe only one or two years. That's when PSY would likely have crossed the 4.2 billion mark. Now imagine when it will reach the 9 quintillion mark.
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @02:24AM
(Views: -1 Troll)
(Score: 1) by steveha on Thursday December 04 2014, @09:59PM
A signed 64-bit integer has a max value of 9223372036854775807. The number from TFA is one higher than that.
(Is there a moderation option "-1, overly pedantic annoying person"?)
(Score: 1) by Ethanol-fueled on Thursday December 04 2014, @10:03PM
Assuming you are correct, that's informative, not annoyingly pedantic.
Annoyingly pedantic are the "its, not it's" types. And the best (worst?) part about those is that they'll often unwittingly make the same mistakes in their "look how smart I am" replies.
(Score: 0) by Anonymous Coward on Thursday December 04 2014, @10:10PM
You start your sentence with an adverb and adjective. Where is the pronoun?
IT! IT is annoyingly pedantic! Say your goddamn pronouns!
(Score: 1) by Bill Evans on Thursday December 04 2014, @10:17PM
He doesn't need a pronoun. He's simply using a (correct) different word order from the following equivalent sentence: The "its, not it's" types are annoyingly pedantic.
(Score: 2) by Arik on Thursday December 04 2014, @11:52PM
There is no need for a pronoun, there is no requirement to start a sentence with one.
"IT! IT is annoyingly pedantic! Say your goddamn pronouns!"
That's low style and sloppy semantics. What is this "it"? Your "it" refers to nothing existential, it's merely a placeholder required by your sloppy grasp of grammar. Not understanding the structure of the sentence, you failed to identify the subject (it's "types") and attempted to use an initial pronoun as a null subject. Since you chose a singular subject you had to change the verbal inflection as well.
All completely pointless. The original sentence was grammatically correct, and stylistically superior to your suggestion.
Please, learn English before you attempt to correct it.
If laughter is the best medicine, who are the best doctors?
(Score: 0) by Anonymous Coward on Friday December 05 2014, @01:02AM
Harumpf. Too many goddammed young'uns around here to get the reference.
How about you learn your cultural references before you attempt to comment on them (and change your goddammend font, don't you know the primary purpose of writing is to effectively communicate, like Mr. Lionel Twain?).
I will tell you, Mr. Wang, if YOU can tell ME why a man who possesses one of the most brilliant minds of this century can't say his *prepositions* or *articles!* "What IS THE," Mr. Wang! "What IS THE meaning of this?"
(Score: 0) by Anonymous Coward on Friday December 05 2014, @11:42AM
Why do you think that everything you know must be a cultural reference shared all over the world?
I for one have no clue what you refer to.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @12:39PM
Rest assured AC, some of us whippersnappers get it. One of my friends was even in a band called "Double Negative, And Dog".
(Score: 3, Informative) by Rivenaleem on Friday December 05 2014, @10:38AM
It's there to handle the Spinal Tap youtube video.
(Score: 3, Informative) by MrGuy on Thursday December 04 2014, @10:06PM
To overflow the new view counter, we'd need 6 billion people (~current earth population) all watching Gangnam Style nonstop (ie restarting as soon as it was over) 24 hours a day for 10,823 years (which is about the length of time from the discovery of agriculture by humans to now).
That's assuming the population of the earth is constant, which it probably wouldn't be, what with all the starvation because we all watch Gangnam Style full time and don't make food anymore...
(Score: 3, Funny) by Buck Feta on Friday December 05 2014, @03:44AM
I can't tell if you are postulating the existence of Hell or disproving it.
- fractious political commentary goes here -
(Score: 0) by Anonymous Coward on Saturday December 06 2014, @10:05AM
Or.....
our little earth Internet gets connected to the Galacticnet and all the Aliens watch it to try to understand why we're so stupid. Then upon realizing that we're a useless race they build a Galatic pot farm on earth wiping out all humans except Wayne and Garth to watch over it. And sample it every now an then.
(Score: 2) by novak on Thursday December 04 2014, @10:07PM
I think the real cause for concern here is that they were using a signed 32 bit integer as the counter. How would you get negative views?
novak
(Score: 2) by bob_super on Thursday December 04 2014, @10:10PM
The MPAA and RIAA would like a chat with you. They make a living off the assertion that someone viewing without their approval is negative revenue (rather than imaginary, since they're a bit square).
(Score: 1) by Lunix Nutcase on Thursday December 04 2014, @10:12PM
Obviously via signed overflow. :-P
(Score: 2) by DECbot on Thursday December 04 2014, @10:50PM
I like the idea of a signed overflow. Not only would you know that the variable overflowed, but you would have a clue by how much it has overflowed.
cats~$ sudo chown -R us /home/base
(Score: 2, Informative) by katterjohn on Thursday December 04 2014, @10:13PM
Google's coding style suggests using signed 32-bit integers or going up to 64-bits:
General style: https://code.google.com/p/google-styleguide/ [google.com]
C++ example: https://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types [googlecode.com]
(Score: 2) by danmars on Thursday December 04 2014, @10:22PM
From your second link:
"If you need a 64-bit integer type, use int64_t or uint64_t."
Looks to me like unsigned is fine with them. Personally, for a counter, I'd always prefer to use an unsigned value.
(Score: 1) by katterjohn on Thursday December 04 2014, @10:29PM
I'd use unsigned integers as well. And I didn't say they were against unsigned integers in general, just (apparently) unsigned 32-bit integers:
"If your variable represents a value that could ever be greater than or equal to 2^31 (2GiB), use a 64-bit type such as int64_t."
(Score: 0) by Anonymous Coward on Thursday December 04 2014, @10:49PM
From the second link to :
You should not use the unsigned integer types such as uint32_t, unless there is a valid reason such as representing a bit pattern rather than a number, or you need defined overflow modulo 2^N. In particular, do not use unsigned types to say a number will never be negative. Instead, use assertions for this.
(Score: 2) by Arik on Thursday December 04 2014, @11:42PM
I'll admit at a glance it looks silly to me - *why* is "this is an absolute value which can never be negative" not a "valid reason" to use an unsigned int?
Isn't that exactly the case that unsigned ints were intended for?
I'll confess I haven't written any C in a long time though, maybe I am missing something?
If laughter is the best medicine, who are the best doctors?
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @01:25AM
I'll admit at a glance it looks silly to me - *why* is "this is an absolute value which can never be negative" not a "valid reason" to use an unsigned int?
Because nothing stops you from assigning it a negative value and your software won't blow up. You'll simply have an erroneous value and a subtle bug that will be fun to debug.
Isn't that exactly the case that unsigned ints were intended for?
No. Not at all.
(Score: 2) by Common Joe on Friday December 05 2014, @06:25AM
I'm not a C or C++ coder, but this is weird logic to me. Nothing stops a programmer from erroneously assigning a signed or unsigned variable a ridiculously high value. In either case, you'll still have an erroneous value and a subtle bug. GGP suggested an assertion. In a counter, what assertion should be used? How high is "too high"? And how often should assertions be coded and run to double check the program is running properly? (Isn't this what unit tests are for?)
One of my biggest gripes about C and Java* is that they don't throw a run-time overflow error when a variable is assigned a value outside of the intended scope. I'm surprised compilers don't automatically put in checks for that and give the programmers an option at compile time to prevent the checks if speed is really needed. Or even better, a syntactic command that allows a section of code not to be checked. (I.e., only disabling checks on a specific section of code.)
* For those who don't believe Java doesn't check for this, check out this guy's blog and run the code yourself: http://www.mkyong.com/java/javas-silent-killer-buffer-overflow-careful/ [mkyong.com]. He doesn't explain it well, but it's a great example he gives. The only difference in the code is the "24" vs "24L".
I understand that there could be other uses for an unsigned int, but this reply doesn't make sense to me. It basically saying that you're purposely limiting yourself to a reduced upper bound rather than pushing as high as the technological upper bound will allow you. And why? So that you can detect an error IF a particular bit is erroneously changed... and if that bit is changed, it doesn't even throw an error and stop execution of that code. It will happily continue using it. One of your users will have to see a weird number which will make no sense to them and report that as a bug. (If we're doing that, why not let the user report a ridiculously large number as a weird number instead of the negative?) Again, your logic makes no sense to me. Can you enlighten me as to what I'm missing?
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @04:17PM
I'm not a C or C++ coder, but this is weird logic to me. Nothing stops a programmer from erroneously assigning a signed or unsigned variable a ridiculously high value. In either case, you'll still have an erroneous value and a subtle bug.
Sure, that's why you use assertions and limits.h. Simply defining unsigned int does not actually prevent any errors it just subtlety masks them.
In a counter, what assertion should be used? How high is "too high"?
Assertion for what? For too high of values you'd do something like:
For making sure you don't pass a negative signed value to an unsigned value you'd do something like:
And how often should assertions be coded and run to double check the program is running properly?
Assertions should be coded and run in all such places that you can potentially have things like buffer overflows, integer overflows, possible null pointers, etc. where execution should be halted rather than continuing with potentially bad side effects. The problem is that not all such examples as I posted will necessarily cause a program to crash and the cost of some extra lines of assertions tends to be a good tradeoff vs exploitable bugs.
(Isn't this what unit tests are for?)
Only if you believe that unit tests can cover the entire range of possible values that can be passed along and handles all different cases of overflow, etc. In the real world, unit tests never cover all such possibilities.
One of my biggest gripes about C and Java* is that they don't throw a run-time overflow error when a variable is assigned a value outside of the intended scope. I'm surprised compilers don't automatically put in checks for that and give the programmers an option at compile time to prevent the checks if speed is really needed. Or even better, a syntactic command that allows a section of code not to be checked. (I.e., only disabling checks on a specific section of code.)
I know MSVC will through such run-time errors be default when you are running in debug mode. It also has a flag to do such checking for release builds as well. I know GCC also has flags that generate traps for signed overflow for addition, subtraction and multiplication. I'm sure LLVM/Clang has something similar.
I understand that there could be other uses for an unsigned int, but this reply doesn't make sense to me. It basically saying that you're purposely limiting yourself to a reduced upper bound rather than pushing as high as the technological upper bound will allow you. And why? So that you can detect an error IF a particular bit is erroneously changed... and if that bit is changed, it doesn't even throw an error and stop execution of that code. It will happily continue using it. One of your users will have to see a weird number which will make no sense to them and report that as a bug. (If we're doing that, why not let the user report a ridiculously large number as a weird number instead of the negative?) Again, your logic makes no sense to me. Can you enlighten me as to what I'm missing?
I might have misinterpreted their meaning. My point is that using unsigned in and of itself offers no guarantee that you are only working with non-negative numbers. Too many novices in C or C++ will actually believe this is the case and by using unsigned values without properly checking the values being passed into that value being in the valid range will potentially be creating exploitable bugs. It's sort of like how you can define a method like this in C:
Now to someone unfamiliar enough with C they might actually think that this method signature actually limits the size of the array that can be passed in. Unfortunately such is not the case and what this really looks like is:
Because of this, one can pass an array smaller in size than the programmer was expecting and cause a potentially exploitable buffer overflow.
(Score: 2, Informative) by Lunix Nutcase on Friday December 05 2014, @01:33AM
In case you need an example of why using unsigned does nothing check this [ideone.com] out.
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @01:39AM
Sorry to triple post, but this example [ideone.com] follows what Google says to do. Notice how we've now prevented working with erroneous values because we immediately hit an assertion failure.
(Score: 2) by Arik on Friday December 05 2014, @02:34PM
Of course I would laugh at anyone deliberately declaring a variable unsigned because it would never need to interact with negative values, then turning around and loading a negative value to it like this - but I can see the broader point that with a complex program and code re-use possibilities and so on it's probably a very good idea to do such redundant/paranoid sanity checks just in case.
The google page linked earlier seems to go further however. It says do not use unsigned ints in this situation at all, if I am not misunderstanding. So while you appear to be saying to go ahead and use the unsigned int, just add assert for sanity check, they seem to be saying use the assert with a signed int as well?
That looks to me to go beyond redundant and paranoid all the way to the land of deliberate self-harm for no gain. But again maybe I am missing something.
If laughter is the best medicine, who are the best doctors?
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @03:59PM
Of course I would laugh at anyone deliberately declaring a variable unsigned because it would never need to interact with negative values, then turning around and loading a negative value to it like this - but I can see the broader point that with a complex program and code re-use possibilities and so on it's probably a very good idea to do such redundant/paranoid sanity checks just in case.
That was a contrived example that wouldn't happen. What is more likely to happen is a method defined with unsigned integers but is passed in a negative value from some external caller. It could even be the value of some expression that could potentially pass a negative value through via some form of overflow. The issue is that simply declaring something to be unsigned does not actually prevent negative values from being used.
(Score: 2) by Arik on Friday December 05 2014, @04:35PM
Well it does prevent it from taking a negative value, but does not guarantee that type conversions are done appropriately when it interacts other sorts of variables. You have to either use asserts or do some sort of explicit conversion just about anytime different types of variables interact, right? So you can use the assert and flag it as an error, if it's never supposed to happen, or you could just e.g. in your example convert the unsigned int into a larger signed positive int before comparing it with a signed int. Right?
It has been years but I remember a substantial portion of my C course dealing with implicit conversions and casting, isnt this something considered pretty basic to learning the language still?
If laughter is the best medicine, who are the best doctors?
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @04:46PM
Well it does prevent it from taking a negative value, but does not guarantee that type conversions are done appropriately when it interacts other sorts of variables.
But it doesn't prevent anything. It simply implicitly converts the negative to an erroneous unsigned value and you'll have been none of the wiser. That's where you possibly end up getting into dangerous territory even if in this case it was a harmless thing.
You have to either use asserts or do some sort of explicit conversion just about anytime different types of variables interact, right? So you can use the assert and flag it as an error, if it's never supposed to happen, or you could just e.g. in your example convert the unsigned int into a larger signed positive int before comparing it with a signed int. Right?
It's actually good to do both. If you are mixing signed and unsigned you should never leave anything up to implicit conversions.
It has been years but I remember a substantial portion of my C course dealing with implicit conversions and casting, isnt this something considered pretty basic to learning the language still?
It should be and one would love to believe this is the case. In practice it is far less the norm than you would believe. It's a lot like how people should be making sure not to run off the end of arrays but that still happens.
(Score: 2) by Open4D on Friday December 05 2014, @03:03PM
I presume so. But perhaps Google believe that lots of people try instead to use unsigned ints to protect against the possibility of negative values, and that this is a mistake of sufficient pervasiveness as to warrant possibly excessive guidelines.
There's also the section below the one you quoted. It seems to be trying to explain some problem(s). Excerpt: "Basically, C's type-promotion scheme causes unsigned types to behave differently than one might expect." But I don't understand, because I don't know C.
(Score: 0) by Anonymous Coward on Friday December 05 2014, @03:28PM
Well, consider the following code:
Now guess what the code does.
(Score: 2) by Open4D on Friday December 05 2014, @03:46PM
Interprets the bit pattern of unsigned int B as representing a signed int (rather than converting it into signed int of the same value) at the time of the comparison with A?
(Score: 0) by Anonymous Coward on Friday December 05 2014, @08:52PM
No, what happens is that the int gets implicitly promoted to an unsigned int which gives it a value far higher than the unsigned value.
(Score: 1) by Lunix Nutcase on Friday December 05 2014, @07:01PM
I presume so. But perhaps Google believe that lots of people try instead to use unsigned ints to protect against the possibility of negative values, and that this is a mistake of sufficient pervasiveness as to warrant possibly excessive guidelines.
Excessive? Android code verification bug from 2013 brought to you via a signed-unsigned mismatch [sophos.com].