dynamicCall and QByteArray - strange characters

[wysota]

You found the value 1234567890 in the first 4 bytes??? Really?

Sure.

If yes please help me to extract and show it as I'm becoming crazy.

Take a calculator (preferably one that understands hex) and calculate it yourself from the hex dump you provided

Or simply ask Google - 0x499602d2 in decimal.

[franco.amato]

Sure.


Take a calculator (preferably one that understands hex) and calculate it yourself from the hex dump you provided

Or simply ask Google - 0x499602d2 in decimal.

I tried these code:

QByteArray ba =  m_axobj->dynamicCall("GetUserData(QString)", myCardId ).toByteArray();
 
int cardIdBE = 0;
memcpy( &cardIdBE, ba, sizeof(int) );
int cardIdLE = qFromBigEndian(cardIdBE);
qDebug() << cardIdLE; //1234567890

QByteArray ba =  m_axobj->dynamicCall("GetUserData(QString)", myCardId ).toByteArray();
			
int cardIdBE = 0;
memcpy( &cardIdBE, ba, sizeof(int) );
int cardIdLE = qFromBigEndian(cardIdBE);
qDebug() << cardIdLE; //1234567890

To copy to clipboard, switch view to plain text mode 

And it returns the correct value,
thank you

[wysota]

You should use qint32 (or quint32 if the number is unsigned) and not int.

[franco.amato]

You should use qint32 (or quint32 if the number is unsigned) and not int.

Wysota how can I do to convert from bigendian some bytes of the qbytearray?
For example I would convert from bigendian the bytes from ba[14] to ba[28] ( 15 bytes ).

I did this

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

To copy to clipboard, switch view to plain text mode 

now I would convert from bigendian the content of name to display the name.
but the qFromBigEndian doesn't return as value a char[] so I can not display correct a name

[faldzip]

Wysota how can I do to convert from bigendian some bytes of the qbytearray?
For example I would convert from bigendian the bytes from ba[14] to ba[28] ( 15 bytes ).

I did this

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

To copy to clipboard, switch view to plain text mode 

now I would convert from bigendian the content of name to display the name.
but the qFromBigEndian doesn't return as value a char[] so I can not display correct a name

qFromBigEndian() is a template function and returns type given in template call.

But... Can you name a type which has a 15 bytes?? I don't know such type... they rather have 2^n bytes, so what type do you want to get?

[wysota]

Wysota how can I do to convert from bigendian some bytes of the qbytearray?
For example I would convert from bigendian the bytes from ba[14] to ba[28] ( 15 bytes ).

I did this

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

To copy to clipboard, switch view to plain text mode 

now I would convert from bigendian the content of name to display the name.
but the qFromBigEndian doesn't return as value a char[] so I can not display correct a name

I think you should first learn what "big-endian" and "little-endian" actually mean and whether they have any application in this context.

[franco.amato]

I think you should first learn what "big-endian" and "little-endian" actually mean and whether they have any application in this context.

I know what [big-little]endian is, the bit alignment, depending of cpus.
In my case I have a processor that align in bigendian and to show the data in my pc I have to convert in littleendian

[wysota]

I know what [big-little]endian is,

I don't think you do.

the bit alignment, depending of cpus.

It has nothing to do with neither "bit" nor "alignment".

In my case I have a processor that align in bigendian and to show the data in my pc I have to convert in littleendian

Please, do me a favour and read about it again, because you are wrong.

[franco.amato]

I don't think you do.


It has nothing to do with neither "bit" nor "alignment"..

In computing, endianness is the ordering of individually addressable sub-units (words, bytes, or even bits) within a longer data word stored in external memory. From http://en.wikipedia.org/wiki/Endianness ( It has nothing to do with bit ?? alignement or ordering for me is the same )

Please, do me a favour and read about it again, because you are wrong.

Maybe my english is not perfect and I'm not able to well explain but I know what big or little endian is

[wysota]

alignement or ordering for me is the same

Well, maybe it's the same for you but it's not the same. And please go past what is written in wikipedia. That's a source of "information" not a source of information.

Maybe my english is not perfect and I'm not able to well explain but I know what big or little endian is

Good, let's see that. Let's assume the following data has been written on a big-endian machine:

quint32 x = 0x12345678;
const char *str = "abcd"; // remember about implicit '\0' at the end of the string

quint32 x = 0x12345678;
const char *str = "abcd"; // remember about implicit '\0' at the end of the string

To copy to clipboard, switch view to plain text mode 

Could you please tell me how a little-endian machine would interpret values of both variables (assuming it was somehow loaded directly into its memory core)? Just please don't write a program to do it, just use your mind, all the needed data is here.

Edit: sorry, one thing that may be important is missing here - do it assuming both machines are 32bit architectures.

[franco.amato]

Well, maybe it's the same for you but it's not the same. And please go past what is written in wikipedia. That's a source of "information" not a source of information.


Good, let's see that. Let's assume the following data has been written on a big-endian machine:

quint32 x = 0x12345678;
const char *str = "abcd"; // remember about implicit '\0' at the end of the string

quint32 x = 0x12345678;
const char *str = "abcd"; // remember about implicit '\0' at the end of the string

To copy to clipboard, switch view to plain text mode 

Could you please tell me how a little-endian machine would interpret values of both variables (assuming it was somehow loaded directly into its memory core)? Just please don't write a program to do it, just use your mind, all the needed data is here.

Edit: sorry, one thing that may be important is missing here - do it assuming both machines are 32bit architectures.

0x78563412 in first case and
"dcba" in second case

[wysota]

0x78563412 in first case and
"dcba" in second case

Are you sure? You can still change something if you want. Take your time...

[franco.amato]

Are you sure? You can still change something if you want. Take your time...

No I don't change. It should be so

[wysota]

Ok, if you say so... You are wrong, the proper answer is:

0x78563412 or 0x56781234 in first case (both forms are correct little-endian encodings, even your wikipedia article says that when you bother to read the whole article and not only the first few lines) and "abcd" in second case.

Character strings are opaque for the processor, it doesn't interpret them in any way so there is no point in manipulating the order of bytes in them hence they are always stored as "big-endian". This is very logical, because each character occupies exactly one byte so there is nothing to reverse there and subsequent characters occupy subsequent bytes in memory. Otherwise it wouldn't be possible to iterate character strings and this is where "alignment" kicks in:

quint32 array[4];
quint32 *aPtr = array;
quint32 *aPtr2 = array+1;
int diff1 = (int)(aPtr2) - (int)(aPtr);
char str[4];
char *sPtr =str;
char *sPtr2 = str+1;
int diff2 = (int)(aPtr2) - (int)(aPtr);

quint32 array[4];
quint32 *aPtr = array;
quint32 *aPtr2 = array+1;
int diff1 = (int)(aPtr2) - (int)(aPtr);
char str[4];
char *sPtr =str;
char *sPtr2 = str+1;
int diff2 = (int)(aPtr2) - (int)(aPtr);

To copy to clipboard, switch view to plain text mode 

diff1 will equal 4 and diff2 will equal 1. ints are word-aligned, chars are byte-aligned.

Now that you have all that knowledge, go back to your problem with converting the blob from big-endian and solve it. Think whether this opaque byte array is more related to an array of ints or to an array of chars.

Just a side note - you wouldn't have to do all that if you did what I asked you to a few dozens of posts ago - dump the byte array in ascii format to the console to see what's inside it. I just suspect you don't know how to do that and are afraid to admit it because otherwise you would have done it long ago.

Edit: By the way, even assuming little-endian architectures were storing strings as you described it, your answer would still be incorrect. I told you to look out for the implicit \0 character that is at the end of the string. You answer should be "dcba"+3bytes of garbage+'\0' or '\0'+"dcba".

[franco.amato]

Ok, if you say so... You are wrong, the proper answer is:

0x78563412 or 0x56781234 in first case (both forms are correct little-endian encodings, even your wikipedia article says that when you bother to read the whole article and not only the first few lines) and "abcd" in second case.

Character strings are opaque for the processor, it doesn't interpret them in any way so there is no point in manipulating the order of bytes in them hence they are always stored as "big-endian". This is very logical, because each character occupies exactly one byte so there is nothing to reverse there and subsequent characters occupy subsequent bytes in memory. Otherwise it wouldn't be possible to iterate character strings and this is where "alignment" kicks in:

quint32 array[4];
quint32 *aPtr = array;
quint32 *aPtr2 = array+1;
int diff1 = (int)(aPtr2) - (int)(aPtr);
char str[4];
char *sPtr =str;
char *sPtr2 = str+1;
int diff2 = (int)(aPtr2) - (int)(aPtr);

quint32 array[4];
quint32 *aPtr = array;
quint32 *aPtr2 = array+1;
int diff1 = (int)(aPtr2) - (int)(aPtr);
char str[4];
char *sPtr =str;
char *sPtr2 = str+1;
int diff2 = (int)(aPtr2) - (int)(aPtr);

To copy to clipboard, switch view to plain text mode 

diff1 will equal 4 and diff2 will equal 1. ints are word-aligned, chars are byte-aligned.

Now that you have all that knowledge, go back to your problem with converting the blob from big-endian and solve it. Think whether this opaque byte array is more related to an array of ints or to an array of chars.

Just a side note - you wouldn't have to do all that if you did what I asked you to a few dozens of posts ago - dump the byte array in ascii format to the console to see what's inside it. I just suspect you don't know how to do that and are afraid to admit it because otherwise you would have done it long ago.

char a;
iterate over all size() of the byte array
a = ba[i];
qDebug() << int(a)

I'm not afraid, I'm out of office and I can not access to my code/data

[wysota]

char a;
iterate over all size() of the byte array
a = ba[i];
qDebug() << int(a)

Hmm... what is this supposed to do? It seems it will dump the array as decimal numbers which doesn't say anything new if you already have it dumped as hex.

I'm not afraid, I'm out of office and I can not access to my code/data

I'm not in your office, I don't have access to your code nor to your data but I can make an ascii dump of your byte array at any moment based on what was written in this thread so stop having excuses to everything and start thinking. We're repeating those late-night discussions each day and you are still at ground zero.

[ChrisW67]

Franco. Have a look at your ASCII dump of the block of data. You are interested in 15 chars starting at a certain offset. What order are the characters in?

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

To copy to clipboard, switch view to plain text mode 

What's in name after line 2? Why do you want to change the order of the bytes in this string?

[franco.amato]

qFromBigEndian() is a template function and returns type given in template call.

But... Can you name a type which has a 15 bytes?? I don't know such type... they rather have 2^n bytes, so what type do you want to get?

I only would convert an undefined number of bytes

[wysota]

What's in name after line 2? Why do you want to change the order of the bytes in this string?

He doesn't even have to copy the data, C semantics of character strings is very useful here.

QByteArray ba = ...
const char *dat = ba.constData();
const char *name = dat+14; // or strdup(dat+14) if one wants to have an own copy
printf("NAME: %s\n", name);

QByteArray ba = ...
const char *dat = ba.constData();
const char *name = dat+14; // or strdup(dat+14) if one wants to have an own copy
printf("NAME: %s\n", name);

To copy to clipboard, switch view to plain text mode 

[franco.amato]

Franco. Have a look at your ASCII dump of the block of data. You are interested in 15 chars starting at a certain offset. What order are the characters in?

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

char* name = new char[15];
memcpy( name, &ba[14], sizeof(char)*15); //I copy 15 bytes of ba to name
char* name_converted = new char[15];
name_converted = qFromBigEndian(name);

To copy to clipboard, switch view to plain text mode 

What's in name after line 2? Why do you want to change the order of the bytes in this string?

Dear Chris,
my stream of bytes come from a fingerprint reader that order bytes using bigendian order.
So I read data and to process them I have to first convert to little endian to understand it.
Wysota told that character strings doen't matter so I have to change the order of the rest of my stream