unsigned-integer

Could anyone tell me please what is an efficient algorithm to count the number of leading zeroes in a 32-bit unsigned integer in C programming? This discussion assumes that your compiler either doesn't support the operation or that it doesn't produce good enough assembly. Note that both of these are unlikely nowadays so I'd recommend just using __builtin_clz for gcc or equivalent on your compiler. Note that determining which is the "best" clz algo can only be done by you. Modern processors are complicated beasts and the performance of these algorithm will heavily depend on the platform you run

This is a homework question that I am stuck with. Consider unsigned integer representation. How many bits will be required to store a decimal number containing: i) 3 digits ii) 4 digits iii) 6 digits iv) n digits I know that the range of the unsigned integer will be 0 to 2^n but I don't get how the number of bits required to represent a number depends upon it. Please help me out. Thanks in advance. Well, you just have to calculate the range for each case and find the lowest power of 2 that is higher than that range. For instance, in i), 3 decimal digits -> 10^3 = 1000 possible numbers so you

I have just started learning C and a question has bugged me for a while now. If I write int i = -1; unsigned int j = 2; unsigned int k = -2; What is the type of integer literal -1 and 2 and -2 , and how does it get converted to get stored in signed int and unsigned int ? What is meant by signed integer, is that the property of variable or integer literal too? Like -2 is signed integer and 2 is unsigned integer? First off, -1 is not an integer constant. It's an expression consisting of a unary - operator applied to the constant 1 . In C99 and C11, the type of a decimal integer constant is the

I Learned About 2's Complement and unsigned and signed int. So I Decided to test my knowledge , as far as i know that a negative number is stored in 2's complement way so that addition and subtraction would not have different algorithm and circuitry would be simple. Now If I Write int main() { int a = -1 ; unsigned int b = - 1 ; printf("%d %u \n %d %u" , a ,a , b, b); } Output Comes To Be -1 4294967295 -1 4294967295 . Now , i looked at the bit pattern and various things and then i realized that -1 in 2's complement is 11111111 11111111 11111111 11111111 , so when i interpret it using %d , it

I have a byte[4] which contains a 32-bit unsigned integer (in big endian order) and I need to convert it to long (as int can't hold an unsigned number). Also, how do I do it vice-versa (i.e. from long that contains a 32-bit unsigned integer to byte[4])? Sounds like a work for the ByteBuffer . Somewhat like public static void main(String[] args) { byte[] payload = toArray(-1991249); int number = fromArray(payload); System.out.println(number); } public static int fromArray(byte[] payload){ ByteBuffer buffer = ByteBuffer.wrap(payload); buffer.order(ByteOrder.BIG_ENDIAN); return buffer.getInt(); }

I was looking at this video . Bjarne Stroustrup says that unsigned ints are error prone and lead to bugs. So, you should only use them when you really need them. I've also read in one of the question on Stack Overflow (but I don't remember which one) that using unsigned ints can lead to security bugs. How do they lead to security bugs? Can someone clearly explain it by giving an suitable example? One possible aspect is that unsigned integers can lead to somewhat hard-to-spot problems in loops, because the underflow leads to large numbers. I cannot count (even with an unsigned integer!) how