Thread: Hex Chars to Binary (XOR Swap split)

Originally Posted by drdepoy

i need to exclusive or

Use the Exclusive OR operator ^ for example like this:

Code:

int	a, b, x;
 
a = 111;
b = 0xF6E; /* Hexadecimal literals can be stored by using 0x */
x = a ^ b; /* x now contains the value of a XOR b */

Note: Study this old classic trick to let two numbers exchange places!

Code:

int main( ) {
int a, b;
 
a = 1234;
b = 5678;
 
printf( "a = %i, b = %i\n", a, b );
a ^= b ^= a ^= b; /* Study how this line works! */
printf( "a = %i, b = %i\n", a, b );
 
return 0;
}

Mod Edit: this topic split from http://cboard.cprogramming.com/showthread.php?t=72638

Originally Posted by cwr

But don't ever do it, it's undefined according to the C standard, and is often slower than using a temporary.

Such a technique is of course slower in this example, but it is a good lesson anyway. However, there is cases when this technique is faster, such as when hardware is involved in letting two physically separate RAM (or VRAM) chips exchange blocks of memory, it has been used for that purpose, but then it is hardware XOR gates that is involved not instructions executed by the processor.
If the line

Code:

a ^= b ^= a ^= b;

is undefined according to Standard ANSI C, then can you prove that by pointing out a link or two on the net, etc., to prove this fact? I don't think you are right about it. But if you are I will admit loud and clear that I was wrong!
This code will yield exactly the same result as the above:

Code:

a ^= b;
b ^= a;
a ^= b;

You could always read the FAQ on the topic. Be sure to visit 3.2 also. You can also just search the forums, because people try this all the time. I'm sure if you were so inclined you could visit your favourite search engine and have your question answered there also.

In short, the standard says any time you modify the same object multiple times in the same statement, it is undefined as to the result. Oh, and there's also the problem with signed integer overflow, etc.


Quzah.

Originally Posted by quzah

You could always read the FAQ on the topic. Be sure to visit 3.2 also. You can also just search the forums, because people try this all the time. I'm sure if you were so inclined you could visit your favourite search engine and have your question answered there also.

In short, the standard says any time you modify the same object multiple times in the same statement, it is undefined as to the result. Oh, and there's also the problem with signed integer overflow, etc.
Quzah.

OK wait a minute, that is if you use a macro function! Of course, then, the result is not defined due to side effects, etc. But this is not the case in the code I originally posted, right? I am not using any macro function at all! Now, can you or anybody else point out that the code I originally posted, lets repeat it here again:

Code:

int main( ) {
int a, b;
 
a = 1234;
b = 5678;
 
printf( "a = %i, b = %i\n", a, b );
a ^= b ^= a ^= b; /* Study how this line works! */
printf( "a = %i, b = %i\n", a, b );
 
return 0;
}

has any side effects and the result is therefore not defined, then do it! Point out a link or two to prove it! The one you gave was about macros, and I am not using a macro.

It doesn't matter. Modifying the same object multiple times in the same statement is undefined. Macro or not. I suppose simply quoting the standard isn't good enough either.

6.5.16 Assignment operators
Syntax
1 assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression
assignment-operator: one of
= *= /= %= += -= <<= >>= &= ^= |=
Constraints
2 An assignment operator shall have a modifiable lvalue as its left operand.
Semantics
3 An assignment operator stores a value in the object designated by the left operand. An
assignment expression has the value of the left operand after the assignment, but is not an
lvalue. The type of an assignment expression is the type of the left operand unless the
left operand has qualified type, in which case it is the unqualified version of the type of
the left operand. The side effect of updating the stored value of the left operand shall
occur between the previous and the next sequence point.
4 The order of evaluation of the operands is unspecified. If an attempt is made to modify
the result of an assignment operator or to access it after the next sequence point, the
behavior is undefined.

[edit]
Furthermore, your attempt at self-justification is absurd. Do you really think it makes a difference if you have a macro which states:

Code:

#define swap(a,b) a^=b^=a^=b

versus a single line of code that isn't a macro? Come on now, that's just stupid. A macro is simply a compile time text "search and replace" function. Why on earth would it matter if it was a macro? (Parenthetical exploitation aside.)
[/edit]

[edit2]
Ok, I have to go on here...

You didn't even read 3.2 did you? That has nothing to do with macros.
[/edit2]

Quzah.

I read 3.2 and 3.8 also. Can anybody point out a non-antique C compiler that fails on that line of code? Maby in the past, such as the year 1995 when the text in that link you gave was written, that compiler makers somehow (but I have no clue how) messed up on this and still were granted a "Standard ANSI C" compiler licence? I have never encountered a C compiler to fail on that. Hey try to point out another link on the net rather than pasting some text that you could have cocked up yourself.. a fresh link that talk about this issue! I can hardly believe a compiler can fail on that line of code! It has to work! If anybody is worried, then split up the line in three lines like I also showed, or use a professional compiler. By the way, it can partly be a good test to see if a compiler sucks or not, maby? What happens in Metrowerks CodeWarrior is that it works as expected because it is a professional compiler.

I would even go as far as claiming that this works on a "Standard ANSI C Compiler":

Code:

int		main( ) {
	int		a, b, c;
 
	a = -123;
	b = -456;
	c = -789;
 
	printf( "a = %i, b = %i, c = %i\n", a, b, c );
	a ^= b ^= c ^= a ^= b ^= c ^= a ^= b;
	printf( "a = %i, b = %i, c = %i\n", a, b, c );
 
	return 0;
}

The output shall be:
a = -123, b = -456, c = -789
a = -456, b = -789, c = -123

P.S.
It doesn't matter if the numbers are signed either.

Originally Posted by fischerandom

I read 3.2 and 3.8 also. Can anybody point out a non-antique C compiler that fails on that line of code? Maby in the past, such as the year 1995 when the text in that link you gave was written, that compiler makers somehow (but I have no clue how) messed up on this and still were granted a "Standard ANSI C" compiler licence? I have never encountered a C compiler to fail on that.

No one said a compiler has to fail on it. However, the standard doesn't say any compiler ever has to evaluate that the way you expect it to be evaluated. That's why it's undefined.

Originally Posted by fischerandom

Hey try to point out another link on the net rather than pasting some text that you could have cocked up yourself.. a fresh link that talk about this issue!

You know, I really kept back what I was going to say in my previous post about you, but now, you're begging for it.

Talk about trying backpeddling! Yeah you're right, you ........ing moron. I made up that quote of the standard. Why, instead of formatting it nicely by hand, I purposefully crafted that text, and made it so it looks like a copy-paste job. It's really just some random words I pulled out of my ass. Oh, also, I completely made up everything in the Eskimo FAQ, just so I could make you look stupid.

Hey, it worked!

Originally Posted by fischerandom

I can hardly believe a compiler can fail on that line of code! It has to work! If anybody is worried, then split up the line in three lines like I also showed, or use a professional compiler. By the way, it can partly be a good test to see if a compiler sucks or not, maby? What happens in Metrowerks CodeWarrior is that it works as expected because it is a professional compiler.

No, it doesn't have to work. The standard says it doesn't. End of discussion.

Oh, hey, while I was at it, I made up this entire web site too! I'm sure if you feel like it, you can find more sites out there with some stuff that I made up, just to make you look like an idiot. But that's right, you can't be troubled with searching on your own.


Quzah.

You guys are talking about a possible reality, while I am talking about reality.
To be on the safe side, split up the lines, etc.

No, I'm talking about reality. The reality is, you cannot guarintee the behavior of that line of code. I could make a compiler for the express purpose of making it fail on that line of code, and guess what? My compiler would be 100% ANSI compliant.


Quzah.

>You guys are talking about a possible reality, while I am talking about reality.
I imagine that things are quite different in your little fantasy world of "it works for me, so it must work for everyone".

>To be on the safe side, split up the lines, etc.
At least you also know how to fix your hopelessly broken first attempt.

>I have never encountered a C compiler to fail on that.
How many have you used? Can you honestly tell us that you've tested this on every C compiler in existence and it works? I'm sorry, but those of us that don't have the time to find every compiler and make sure that undefined behavior is uniform across them have to merely go by what the standard says not to do.

Let's get things straight: You're wrong. You're on the losing side of this debate. You should learn C before trying to teach it. I appreciate your willingness to help, and your attempts have been most entertaining, but you're likely to do more harm than good if you keep helping with only a vague idea of what you're talking about.

We're not yet done here. Start defending your side by putting up a bounch of links to Standard C where this issue is discussed in detail to prove you are right, and explicitly prove that this applies to a line like a ^= b ^= a ^= b, etc and not other operators in general. Put ut some fresh link! It's rediculous you guys haven't found anything better than that 1995 link yet, or copied some stuff from an antique book - and who knows what those worried souls got their sources from? What about C99?

>We're not yet done here.
Only because you refuse to do what you said you would do in the beginning: "I don't think you are right about it. But if you are I will admit loud and clear that I was wrong!"

>What about C99?
C99 says the same thing. I'm sorry (very sorry!) to say that I don't have my copy of either the electronic or hardcopy C99 standard available to me at the moment, otherwise I'd be more than happy to quote it verbatim for you.

>Put ut some fresh link!
There's no fresh link to the standard. You have to buy it. If you've been programming for as long as you say, you should already have a copy of the C99 standard. But since you don't have it, and you clearly won't believe that we own and read it, or that anyone else in the world could possibly be getting their information from such an authoritative source, there's no way to convince you that you're being retarded. It's a shame, but some people just refuse to learn.

I highly recommend that you pay the $18 and download your own copy, lest this thread become even more embarrassing for you.