bitwise-operators

Bitwise operator predence

梦想的初衷 提交于 2019-12-07 12:35:38
问题 A gotcha I've run into a few times in C-like languages is this: original | included & ~excluded // BAD Due to precedence, this parses as: original | (included & ~excluded) // '~excluded' has no effect Does anyone know what was behind the original design decision of three separate precedence levels for bitwise operators? More importantly, do you agree with the decision, and why? 回答1: The operators have had this precedence since at least C. I agree with the order because it is the same relative

Bitwise Not Operator (~ in C) with regards to little endian and big endian

我们两清 提交于 2019-12-07 08:30:41
问题 This is in relation to a homework assignment but this is not the homework assignment. I'm having difficultly understanding if there is a difference on how the bitwise not ( ~ in C) would affected signed int and unsigned int when compiled on a big endian machine vs. a little endian machine. Are the bytes really "backwards" and if so does the bitwise not (and other operators) cause different resulting int s be produced depending on the machine type? While we are at it, is the answer the same

C#: Shift left assignment operator behavior

送分小仙女□ 提交于 2019-12-07 04:29:30
问题 I'm running code that sometimes yields this: UInt32 current; int left, right; ... //sometimes left == right and no shift occurs current <<= (32 + left - right); //this works current <<= (32 - right); current <<= left; It appears for any value >= 32, only the value % 32 is shifted. Is there some "optimization" occurring in the framework? 回答1: C# 3.0 language specification, 7.8 "Shift operators": For the predefined operators, the number of bits to shift is computed as follows: When the type of

Why doesn't left bit shifting by 64 overflow in golang?

谁说胖子不能爱 提交于 2019-12-07 04:06:02
问题 I was taking a look at A Tour of Go and I was confused by something in their basic-types.go example: MaxInt uint64 = 1<<64 - 1 Shouldn't shifting a 1 64 positions to the left in an unsigned 64 bit integer cause overflow (a.k.a. shifting a bit past the MSB)? However, the compiler doesn't complain until the line is changed to: MaxInt uint64 = 1<<65 - 1 ./basic-types.go:5: constant 36893488147419103231 overflows uint64 If I write some code to iterate over left shifts of varying lengths,

How does the `test` instruction work?

人走茶凉 提交于 2019-12-07 03:01:20
问题 If we have: test dword ptr [eax], 2000h je label1: Is there any value other than 0 in dword ptr [eax] that would make the jump take place? 回答1: Instruction test works like and instruction, the only difference is that result is not stored back in to the destination operand. So the answer is yes. All binary numbers which not have set the 13th bit on memory address [eax], or all numbers present like b'xxxxxxxx xxxxxxxx xx0xxxxx xxxxxxxx', where x is 0 or 1, there is exactly 2^31 numbers. 来源:

Xor encryption in PHP

一个人想着一个人 提交于 2019-12-07 00:15:25
问题 I'm new to Xor encryption, and I'm having some trouble with the following code: function xor_this($string) { // Let's define our key here $key = ('magic_key'); // Our plaintext/ciphertext $text =$string; // Our output text $outText = ''; // Iterate through each character for($i=0;$i<strlen($text);) { for($j=0;$j<strlen($key);$j++,$i++) { $outText .= $text{$i} ^ $key{$j}; //echo 'i='.$i.', '.'j='.$j.', '.$outText{$i}.'<br />'; //for debugging } } return $outText; } When I run this it works for

How to use bitwise operators to return a 0 or 1

时光总嘲笑我的痴心妄想 提交于 2019-12-06 16:17:56
问题 My function takes in a 32 bit int and I need to return a 0 or 1 if that number has a 1 in any even position. I cant use any conditional statements I also can only access 8 bits at a time. Here is an example input: 10001000 01011101 00000000 11001110 1) Shift the bits and and them with AA(10101010) and store each one in a variable. int a = 10001000 int b = 1000 int c = 0 int d = 10001010 Now I need to return a 0 if there were no odd bits set and 1 if there were. As we can see there were. So I

Undoing shifts without truncating

点点圈 提交于 2019-12-06 15:15:30
I'm a bit baffled by this. Shouldn't the values truncate after the shift? Does anyone know why this happens? long a, b, c, n; //assign any value to a, set b and c to 0x000...0 n = 128; //any number works; b = a << n; c = b >> n; a == (b >> n); // True a == c; //True; Postscript I've always understood that if you shift a buffer in any direction, the values that "fall" outside the buffer size get truncated, and that they're essentially lost unless you get them from the original buffer. Thats been true for every platform I've ever worked with in assembly, and I thought that'd extend to the higher

PHP Bitwise XOR vs. JavaScript Bitwise XOR

这一生的挚爱 提交于 2019-12-06 15:06:18
I'm trying to find a way to make PHP Bitwise XOR results match the results of JavaScript Bitwise XOR . I came across different questions of this issue, and all without answers. Here are a few of them: Javascript & PHP Xor equivalent php bitwise XOR and js bitwise XOR producing different results JS bitwise XOR operator acts differently from PHP’s counterpart. How to get the same result as PHP returns? I know that PHP is using 64 bit compared to 32 bit JavaScript, but my question is, is there any manual way to count similar results? How can we make PHP get similar results as JS? If the numbers

How to define 2-bit numbers in C, if possible?

情到浓时终转凉″ 提交于 2019-12-06 08:36:51
问题 For my university process I'm simulating a process called random sequential adsorption. One of the things I have to do involves randomly depositing squares (which cannot overlap) onto a lattice until there is no more room left, repeating the process several times in order to find the average 'jamming' coverage %. Basically I'm performing operations on a large array of integers, of which 3 possible values exist: 0, 1 and 2. The sites marked with '0' are empty, the sites marked with '1' are