How do I convert an unsigned int (UINT32) to a const char.
I tried to cast it but because isn’t type safe is crashing when the pointer is bigger than expected.
So how can I approach this correctly?
unsigned int p = 0x32422342;
strLocation = QString::fromUtf8((char*)p, sizeof(p));
BTW if I leave the cast, the compiler is showing up an exception:
cast to `const char*`from smaller integer type `UINT32` (aka `unsigned int`) [-Wint-to-pointer-cast]
any suggestions? The value is just a random number, just for clarification.
Your pointers are probably 64 bits long, this is why your compiler complains... Are you sure that your 32 bits represents a good address ? Probably not.
Related
I am reading the Beej's Guide to network programming book and I am having trouble understanding a function. The function expects a char * pointer but it dereferences the pointer and casts it to a (unsigned long int) and perform some bitwise operations. Why couldn't we just pass it as a
(unsigned int *) instead of (unsigned char *). Also if the parameter was replaced by (void *) and then inside code we did some thing like:
*(unsigned long int *)buf[0] << 24
will we get the same result? (Sorry this is my first time asking a question here so let me know if any more info is required).
unsigned long int unpacku32(unsigned char *buf)
{
return ((unsigned long int)buf[0]<<24) |
((unsigned long int)buf[1]<<16) |
((unsigned long int)buf[2]<< 8) |
buf[3];
}
What you're suggesting is not guaranteed to work. Unless buf points to an actual unsigned long, you're attempting to read an object of one type as another which is not allowed (unless you're reading as an unsigned char). There could be further issues if the pointer value you create is not properly aligned for its type.
Then there is also the issue of endianness. Bytes sent over a network are typically sent in big-endian format, i.e. most significant byte first. If your system is little-endian, it will interpret the bytes in the reverse order.
The function you posted demonstrates the proper way of deserializing an unsigned long from a byte buffer in a standard compliant manner.
That would make it dependable on the endianness of the platform. So we pick out the parts from the defined order to make it platform neutral.
buf[0] is treated as 8 bit unsigned value. If we do this:
(unsigned long int)buf[0] << 24, by casting we tell to treat it not as 8 bit value, but as 64 bit so we got more space to work with.
We shifted only buf[0], buf[1] and other fields are not considered during shifting process.
If you want to convert to unsigned long lets say a string "aabbccd" and we don't care about endianness we can do this like below:
char* str = const_cast<char *>("aabbccd\0");
unsigned long value = *(reinterpret_cast<unsigned long *>(str));
std::cout << value << std::endl;
std::cout << reinterpret_cast<char *>(&value) << std::endl;
It should be pointed, unsigned long can store up to 8 chars only, because its 64 bit integer.
However if many platforms are going to use same data, doing it like this maybe be not enough due to endianness. The approach given in your book is as someone mentioned platform neutral.
The function expects a char * pointer but it dereferences the
pointer and casts it to a (unsigned long int) and perform some
bitwise operations.
Actually, what the code does is use the array index operator to pull out the first byte from the buffer, casts that to an unsigned long int, and then does some bitwise operations. The pointer that's dereferenced is an unsigned char * not anything to do with long integers.
Why couldn't we just pass it as a (unsigned int *) instead of
(unsigned char *).
Because it isn't a pointer to any kind of integer. It's a pointer to a buffer of unsigned char, i.e. bytes. Treating a pointer as if it were a pointer to a different type is likely to lead to a violation of the "Strict Aliasing Rule" (which I encourage you to read about).
Also if the parameter was replaced by (void *) and then inside code we
did some thing like *(unsigned long int *)buf[0] << 24 will we get
the same result?
No. If you define buf as a void*, then buf[0] is a meaningless expression. If buf is defined as, or cast to, an unsigned long int *, then buf[0] is an unsigned long int, not the unsigned char that the algorithm is expecting. There will almost certainly be too many bits set (as many as 64, not 8) and the result of the expression will be invalid.
error: invalid static_cast from type ‘unsigned char*’ to type ‘uint32_t* {aka unsigned int*}’
uint32_t *starti = static_cast<uint32_t*>(&memory[164]);
I've allocated an array of chars, and I want to read 4 bytes as a 32bit int, but I get a compiler error.
I know that I can bit shift, like this:
(start[0] << 24) + (start[1] << 16) + (start[2] << 8) + start[3];
And it will do the same thing, but this is a lot of extra work.
Is it possible to just cast those four bytes as an int somehow?
static_cast is meant to be used for "well-behaved" casts, such as double -> int.
You must use reinterpret_cast:
uint32_t *starti = reinterpret_cast<uint32_t*>(&memory[164]);
Or, if you are up to it, C-style casts:
uint32_t *starti = (uint32_t*)&memory[164];
Yes, you can convert an unsigned char* pointer value to uint32_t* (using either a C-style cast or a reinterpret_cast) -- but that doesn't mean you can necessarily use the result.
The result of such a conversion might not point to an address that's properly aligned to hold a uint32_t object. For example, an unsigned char* might point to an odd address; if uint32_t requires even alignment, you'll have undefined behavior when you try to dereference the result.
If you can guarantee somehow that the unsigned char* does point to a properly aligned address, you should be ok.
I am used to BDS2006 C++ but anyway this should work fine on other compilers too
char memory[164];
int *p0,*p1,*p2;
p0=((int*)((void*)(memory))); // p0 starts from start
p1=((int*)((void*)(memory+64))); // p1 starts from 64th char
p2=((int*)((void*)(&memory[64]))); // p2 starts from 64th char
You can use reinterpret_cast as suggested by faranwath but please understand the risk of going that route.
The value of what you get back will be radically different in a little endian system vs a big endian system. Your method will work in both cases.
I have downloaded an image and it is saved in a std::string.
Now I want to use/open it with following conditions:
typedef uint8_t byte //1 byte unsigned integer type.
static open(const byte * data, long size)
How do I cast from string to byte* ?
/EDIT:
i have already tried this:
_data = std::vector<byte>(s.begin(), s.end());
//_data = std::vector<uint8_t>(s.begin(), s.end()); //also fails, same error
_p = &_data[0];
open(_p, _data.size())
but i get:
undefined reference to 'open(unsigned char const*, long)'
why does it interpret byte wrongly as char?!
/EDIT2:
just to test it i changed to function call to
open(*_p, _data.size())
but then i get:
error: no matching function for call to 'open(unsigned char&, size_t)'
[...] open(const byte*, long int) <near match>
So the function is definitly found...
Two possibilities:
1) the common one. On your system, char is either 2's complement or else unsigned, and hence it is "safe" to read chars as unsigned chars, and (if char is signed) the result is the same as converting from signed to unsigned.
In which case, use reinterpret_cast<const uint8_t*>(string.data()).
2) the uncommon one. On your system, char is signed and not 2's complement and hence for char *ptr pointing to a negative value the result of *(uint8_t*)ptr is not equal to (uint8_t)(*ptr). Then depending what open actually does with the data, the above might be fine or you might have to copy the data out of a string and into a container of uint8_t, converting as you go. For example, vector<uint8_t> v(string.begin(), string.end());. Then use &v[0] provided that the length is not 0 (unlike string, you aren't permitted to take a pointer to the data of an empty vector even if you never dereference it).
Non-2's-complement systems are approximately non-existent, and even if there was one I think it's fairly unlikely that a system on which char was signed and not 2's complement would provide uint8_t at all (because if it does then it must also provide int8_t). So (2) only serves pedantic completeness.
why does it interpret byte wrongly as char
It isn't wrong, uint8_t is a typedef for unsigned char on your system.
std::string string_with_image;
string_with_image.data();
Hi I'm trying to use the code from, http://blog.firetree.net/2006/08/23/nasa-srtm-elevation-data/, with no success, after much chasing around I found where it is failing, but have no idea how to fix it, please help, this has been doing my head in for about 6 hours.
This is the line that fails. data is a void pointer to a memory mapped file.
unsigned short datum=((unsigned short*)data)[i];
I'm on OpenSuse using the gcc compiler. I'm on a 64bit system.
Thanks in advance.
I think maybe this is caused by the memory alignment.
in some platform pointer value can't be cast to some types.
for example, a platform needs int* should be aligned with 4, so 0x12345 can be void* or char*, but if you assigned it to int*, crash happened.
for your situation,
you can cast the void pointer to unsigned char* first, then convert 2 unsigned chars to unsigned short:
unsigned char a =((unsigned char*)data)[i];
unsigned char b =((unsigned char*)data)[i+1];
if (platform_is_little_endian()) {
unsigned short datatum = (b << sizeof(unsigned char)) | a;
}
else {
// platform is big endian
unsigned short datatum = (a << sizeof(unsigned char)) | b;
}
If you're saying it crashes at that point, then I would imagine you were reading outside of the array. But storing a pointer to an unsigned short as an unsigned short is interesting to say the least, does that even compile?
Solved by a combination of Donald Tangs method and the realization that the program was reading outside the array. For other potential users the problem occurs when finding the value of num_rows num_cols as the authors square root function doesn't square root.
Is it safe to convert, say, from an unsigned char * to a signed char * (or just a char *?
The access is well-defined, you are allowed to access an object through a pointer to signed or unsigned type corresponding to the dynamic type of the object (3.10/15).
Additionally, signed char is guaranteed not to have any trap values and as such you can safely read through the signed char pointer no matter what the value of the original unsigned char object was.
You can, of course, expect that the values you read through one pointer will be different from the values you read through the other one.
Edit: regarding sellibitze's comment, this is what 3.9.1/1 says.
A char, a signed char, and an unsigned char occupy the same amount of storage and have the same alignment requirements (3.9); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers.
So indeed it seems that signed char may have trap values. Nice catch!
The conversion should be safe, as all you're doing is converting from one type of character to another, which should have the same size. Just be aware of what sort of data your code is expecting when you dereference the pointer, as the numeric ranges of the two data types are different. (i.e. if your number pointed by the pointer was originally positive as unsigned, it might become a negative number once the pointer is converted to a signed char* and you dereference it.)
Casting changes the type, but does not affect the bit representation. Casting from unsigned char to signed char does not change the value at all, but it affects the meaning of the value.
Here is an example:
#include <stdio.h>
int main(int args, char** argv) {
/* example 1 */
unsigned char a_unsigned_char = 192;
signed char b_signed_char = b_unsigned_char;
printf("%d, %d\n", a_signed_char, a_unsigned_char); //192, -64
/* example 2 */
unsigned char b_unsigned_char = 32;
signed char a_signed_char = a_unsigned_char;
printf("%d, %d\n", b_signed_char, b_unsigned_char); //32, 32
return 0;
}
In the first example, you have an unsigned char with value 192, or 110000000 in binary. After the cast to signed char, the value is still 110000000, but that happens to be the 2s-complement representation of -64. Signed values are stored in 2s-complement representation.
In the second example, our unsigned initial value (32) is less than 128, so it seems unaffected by the cast. The binary representation is 00100000, which is still 32 in 2s-complement representation.
To "safely" cast from unsigned char to signed char, ensure the value is less than 128.
It depends on how you are going to use the pointer. You are just converting the pointer type.
You can safely convert an unsigned char* to a char * as the function you are calling will be expecting the behavior from a char pointer, but, if your char value goes over 127 then you will get a result that will not be what you expected, so just make certain that what you have in your unsigned array is valid for a signed array.
I've seen it go wrong in a few ways, converting to a signed char from an unsigned char.
One, if you're using it as an index to an array, that index could go negative.
Secondly, if inputted to a switch statement, it may result in a negative input which often is something the switch isn't expecting.
Third, it has different behavior on an arithmetic right shift
int x = ...;
char c = 128
unsigned char u = 128
c >> x;
has a different result than
u >> x;
Because the former is sign-extended and the latter isn't.
Fourth, a signed character causes underflow at a different point than an unsigned character.
So a common overflow check,
(c + x > c)
could return a different result than
(u + x > u)
Safe if you are dealing with only ASCII data.
I'm astonished it hasn't been mentioned yet: Boost numeric cast should do the trick - but only for the data of course.
Pointers are always pointers. By casting them to a different type, you only change the way the compiler interprets the data pointed to.