2 bytes to short

Can you give me an example? I think this threrad is where you should explain.

(code may not be correct)
A char is as an int, a series of binary values. and a series of chars is a string, correct?

int BLA = (int)( ( (*STRING)[x] >> n ) & 0xFF...F );

(*STRING)[x] <-- points to a char

((*STRING)[x])>>n) <-- shift the values of the char

(int)( ( (*STRING)[x] >> n ) & 0xFF...F ) <-- ... mask to save the intended data in an int instead... vola you have your values from the stream of 2 byte chars.

i'm assuming the data is formatted in to a stream of bits really, which is captures as 2byte chars, but can contain other data... this is a way to get that data.

in one of my projects values are received as a stream of bits representing INT values, each int has two shorts formatted in it, for two channels of data... i capture both channels in a similar fashion as above.

unless i'm talking about an idea that still doesn't apply, i'm only suggesting from what it sounds like to me that this can apply.

let's say the standard is first 16 bits is a short, the rest is what ever, then when you capture this information you can apply bit manipulation to get the formatted data as intended.

if STRING is a char pointer.
(*STRING)[x] <-- Doesn't point to anything. derefferenced twice!

from one of my projects:

static int j = 0;
for (j=0; j<SMPSIZE; ++j)
{
chL = (((int *)alBuffer)[j] >> 0) & 0xFFFF; // -32768 -> 32767
chR = (((int *)alBuffer)[j] >> 16) & 0xFFFF; // -32768 -> 32767

vChL.push_back( chL / float(SHRT_MAX) );
vChR.push_back( chR / float(SHRT_MAX) );
}


alBuffer is a buffer holding streamed data as ALint type. See what I'm talking about?

If he needs data out of a stream, formatted a specific way, he do the same thing, regardless if it's chars or what ever.

I think it wont work for string. I'm waiting for vart to explain. Maybe he thinks data are overlapped on byte boudaries. Then you may use bitwise operation. Otherwise I don't see any need.

Code:

---

int BLA = (int)( ( (STRING)[x] >> n ) & 0xFF...F );

(STRING)[x] <-- points to a char

((STRING)[x])>>n) <-- shift the values of the char

---

OK. It works. Now our problem:
We have string like this:

Code:

---

01101101|01011101|11011010|11000001

---

Suppose "data" is pointing to first byte with index '0'. It is data[0] == *data. Now if we do a bitwise operation on byte 3 (data[2]), compiler see only one byte to manipulate not its neigbors. We don't need it in this case as I can see.

Suppose I have

short unsigned value = 0xABCD;

And I need to send it to another process using socket...
I will use
send(fd,&value, sizeof value);
Right? Wrong... This will make my code unportable and cause problems if the sender and reciever are using different endian architecture...
What will I do, I will construct a byte array like this:

Code:

---

unsigned char data[2];
data[0] = value & 0xFF; /* low byte */
data[1] = (value >> 8) & 0xFF; /* high byte */
send(fd, data, sizeof data);

---

What will I do after receiving char array to restore the sent value?

Code:

---

value = data[1];
value <<= 8;
value |= data[0];

---

In this case I'm not interested to know if the byte order on sender and receiver for representing short is the same or not;

Tricky method. It works because in the platform that executes:

Code:

---

data[0] = value & 0xFF; /* low byte */

---

System knows that low byte is the bigger or smaller byte address, so data[0] will have the low byte. And reverse operation is done in destination. Data in the network will be big endian. Right?
In this case we don't know if its true or not.

Quote:

---

Data in the network will be big endian. Right?
In this case we don't know if its true or not

---

This is why you do your research and learn the standards in formatting data for various protocols. Which is out of the scope for solving the technical issue, which is what we're providing. How the information is received on the other end is irrelevant since you capture information designed to work in what ever protocol you are communicating over. You have to trust at the other end the software is written to capture and present the information correctly. You have to assume that the information being sent to you as well was formatted correctly as the standard requires for what ever protocol your using, so you can assume how the information will get to you.

If you're writing both the server and client side, then you have to make sure you understand how information is formatted on both local systems and write your code accordingly.

There's no guess work involved. This is why standards for communicating over networks exist, and why people abide by them.

So you don't need to worry if the information will get to you as it should, as long as everyone agrees to the standards you're guaranteed the data to be intact as documented. So you do know the binary format, by understanding what your capturing information from, which the programmer must know to capture the data he wants to represent it.

The solution was after this point, how to get the meaningful data out of the stream, this is via bitwise operators shifting stream information and masking to extract the intended data, as said above.


I hope I didn't misunderstand you, but it seems that was your concern.