string operation??

[sethukr]

hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

-Sethu

[mark_bluemel]

se*****@gmail.com wrote:

hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

This isn't a mobile phone. "please" is only a little more typing than
"plz", and the shift key is easy to find. Basic typography a) improves
the readibility of your message and b) makes the reader feel that you
bothered to put in some effort.

Now to the question. In "str[0]^=str[1]" you are not operating on a
string, but on a character in that string. We are doing an exclusive
bitwise or operation with the first two characters and storing the
result in the first. Why the code is doing that is beyond me, though
I'd suspect it was a crude cryptographic technique....

[santosh]

se*****@gmail.com wrote:

hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

Please avoid abbreviations like plz instead of please, since this is an
international forum and many posters may not know it's meaning.

The bit pattern of the char value at str[1] is taken and an exclusive
OR operation is done with the bit pattern of the char value at str[0]
and the result in stored back to str[0].

The ^= is a compound assignment operator.

[Bob Martin]

in 707477 20061127 112944 "santosh" <sa*********@gmail.comwrote:

>se*****@gmail.com wrote:

>hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

Please avoid abbreviations like plz instead of please, since this is an
international forum and many posters may not know it's meaning.

The bit pattern of the char value at str[1] is taken and an exclusive
OR operation is done with the bit pattern of the char value at str[0]
and the result in stored back to str[0].

The ^= is a compound assignment operator.

Which would be clearer with spaces either side of the operator
(especially to a Pascal programmer).

[santosh]

Bob Martin wrote:

in 707477 20061127 112944 "santosh" <sa*********@gmail.comwrote:

se*****@gmail.com wrote:

hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

Please avoid abbreviations like plz instead of please, since this is an
international forum and many posters may not know it's meaning.

The bit pattern of the char value at str[1] is taken and an exclusive
OR operation is done with the bit pattern of the char value at str[0]
and the result in stored back to str[0].

The ^= is a compound assignment operator.

Which would be clearer with spaces either side of the operator
(especially to a Pascal programmer).

Yes, it seems popular among many newbies to eschew whitespace, and C
seems particularly prone to this trend!

[Christopher Benson-Manica]

ma**********@pobox.com wrote:

char str[10]="string";
str[0]^=str[1];

Now to the question. In "str[0]^=str[1]" you are not operating on a
string, but on a character in that string. We are doing an exclusive
bitwise or operation with the first two characters and storing the
result in the first. Why the code is doing that is beyond me, though
I'd suspect it was a crude cryptographic technique....

Is it implementation-defined whether the above code yields undefined
behavior or not? (If char is signed, may str[0]^=str[1] not generate
a trap representation?)

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Random832]

2006-11-27 <ek**********@chessie.cirr.com>,
Christopher Benson-Manica wrote:

ma**********@pobox.com wrote:

char str[10]="string";
str[0]^=str[1];

>Now to the question. In "str[0]^=str[1]" you are not operating on a
string, but on a character in that string. We are doing an exclusive
bitwise or operation with the first two characters and storing the
result in the first. Why the code is doing that is beyond me, though
I'd suspect it was a crude cryptographic technique....

Is it implementation-defined whether the above code yields undefined
behavior or not? (If char is signed, may str[0]^=str[1] not generate
a trap representation?)

Is CHAR_MAX allowed to be a value other than a power of two minus one?

[Spiros Bousbouras]

Christopher Benson-Manica wrote:

ma**********@pobox.com wrote:

char str[10]="string";
str[0]^=str[1];

Now to the question. In "str[0]^=str[1]" you are not operating on a
string, but on a character in that string. We are doing an exclusive
bitwise or operation with the first two characters and storing the
result in the first. Why the code is doing that is beyond me, though
I'd suspect it was a crude cryptographic technique....

Is it implementation-defined whether the above code yields undefined
behavior or not? (If char is signed, may str[0]^=str[1] not generate
a trap representation?)

Probably not. Footnote 44 on page 38 of N1124 says

Some combinations of padding bits might
generate trap representations, for example,
if one padding bit is a parity bit. Regardless,
no arithmetic operation on valid values can
generate a trap representation other than as
part of an exceptional condition such as an
overflow, and this cannot occur with unsigned
types.

I'm not completely certain that bitwise operators count
as arithmetic operators but they should be. Plus it
feels that char1 ^= char2 should be harmless regardless
whether char1 and char2 are signed or unsigned.

[Spiros Bousbouras]

Random832 wrote:

Is CHAR_MAX allowed to be a value other than a power of two minus one?

In N1124, 6.2.6.2., paragraph 1 we read

For unsigned integer types other than
unsigned char, the bits of the object
representation shall be divided into two
groups: value bits and padding bits (there
need not be any of the latter). If there are N
value bits, each bit shall represent a different
power of 2 between 1 and 2^(N-1), so that objects
of that type shall be capable of representing values
from 0 to 2^N - 1 using a pure binary representation;
this shall be known as the value representation.

And in paragraph 2 we read

For signed integer types, the bits of the object
representation shall be divided into three groups:
value bits, padding bits, and the sign bit. There
need not be any padding bits; there shall be exactly
one sign bit. Each bit that is a value bit shall have
the same value as the same bit in the object
representation of the corresponding unsigned type
(if there are M value bits in the signed type and N in
the unsigned type, then M <= N).

>From the above I'm led to think that the maximum value

of any integer type is a power of 2 minus 1.

[Harald van Dijk]

Spiros Bousbouras wrote:

Christopher Benson-Manica wrote:

ma**********@pobox.com wrote:

char str[10]="string";
str[0]^=str[1];

Now to the question. In "str[0]^=str[1]" you are not operating on a
string, but on a character in that string. We are doing an exclusive
bitwise or operation with the first two characters and storing the
result in the first. Why the code is doing that is beyond me, though
I'd suspect it was a crude cryptographic technique....

Is it implementation-defined whether the above code yields undefined
behavior or not? (If char is signed, may str[0]^=str[1] not generate
a trap representation?)

Probably not. Footnote 44 on page 38 of N1124 says

Some combinations of padding bits might
generate trap representations, for example,
if one padding bit is a parity bit. Regardless,
no arithmetic operation on valid values can
generate a trap representation other than as
part of an exceptional condition such as an
overflow, and this cannot occur with unsigned
types.

I'm not completely certain that bitwise operators count
as arithmetic operators but they should be.

They are, however this footnote only addresses trap representations as
a result of padding bits, which makes sense since it is attached to a
description of unsigned types. Signed types have another possibility
for a trap representation.

Plus it
feels that char1 ^= char2 should be harmless regardless
whether char1 and char2 are signed or unsigned.

If CHAR_MIN equals -CHAR_MAX and the implementation does not support
negative zeroes, it's possible to generate a trap representation using
the bitwise operators. However, since for this the sign bit must be
set, and 's' and 't' must both be positive, there's no problem with the
original code.

[Random832]

2006-11-27 <11*********************@l12g2000cwl.googlegroups. com>,
Spiros Bousbouras wrote:

Random832 wrote:

>Is CHAR_MAX allowed to be a value other than a power of two minus one?

[snip]

>
From the above I'm led to think that the maximum value
of any integer type is a power of 2 minus 1.

In that case, regarding the question which you snipped about 's'^'t'
yielding a trap representation, it's not possible, since the xor
operation is defined mathematically in such a way as that if you take
any two positive numbers less than or equal CHAR_MAX, the result will be
another positive number less than or equal to CHAR_MAX. And characters
in the basic execution character set are guaranteed to be positive.

[Simon Biber]

santosh wrote:

se*****@gmail.com wrote:

>hi everybody,

char str[10]="string";
str[0]^=str[1];

can anybody plz tell me the use of ^operator in string???

The bit pattern of the char value at str[1] is taken and an exclusive
OR operation is done with the bit pattern of the char value at str[0]
and the result in stored back to str[0].

Yes. In the specific case of ASCII encoded strings, which is quite
likely, the values involved will be 115 ('s') and 116 ('t').

In decimal, 115 ^ 116 = 7

In binary, 01110011 ^ 01110100 = 00000111

Again assuming ASCII, the value 7 is the alert character '\a', also
known as BEL or CTRL-G. Attempting to print str after this xor operation
will probably result in an audible beep followed by the characters
"tring" which were unchanged.

--
Simon.