C++ Read access violation for vector - c++

Question

Im getting an exception when I`m trying to use vector[int_number] and my program stop working.
uint64_t data = 0xffeeddccbbaa5577;
uint16_t *vector = (uint16_t*) data;
int currentPosition = 0;
while (currentPosition <= 3) {
uint16_t header = vector[currentPosition]; // problem here
Visual Studio 2017 returns me: Unhandled exception thrown: read access violation.
vector was 0x6111F12.
Im stuck here. If you have any idea what I should do I`ll be grateful. Thanks in advance!

Answer 1

Setting aside all the undefined behaviour you get due to strict aliasing violations, in the current crop of Intel chips and MSVC runtime, all pointers are 48 bits.
So 0xffeeddccbbaa5577 is never a valid pointer value.
So the behaviour on dereferencing that value will be undefined.
If you wanted to break up data, into four elements of an appropriate type, then one method is to create a uint16_t foo[4] say and memcpy the data starting at &data to foo.

Answer 2

By accessing the data through a pointer of different type you obtained by casting you wander off into undefined-behavior-land. Instead of this, try the following (note I also replaced your while loop with a ranged for loop avoiding to have to keep a counter)
#include <iostream>
#include <cstring>
int main() {
uint64_t data = 0xffeeddccbbaa5577;
uint16_t vector[4];
memcpy(vector, &data, sizeof(uint64_t));
for (uint16_t header : vector)
{
std::cout << std::hex << header << std::endl;
}
}
yielding
5577
bbaa
ddcc
ffee
If you use reinterpret_cast you hold two pointers of different type pointing to same address which may easily lead to undefined behavior. memcpy avoids that by creating a copy of the memory location and you may safly access it with a pointer of a different type. Also take a look into type-punning (as pointed out by #DanielLangr)

Answer 3

It's really very easy, but you were so far off with your original attempt that you've confused everyone.
uint16_t vector[] = { 0x5577, 0xbbaa, 0xddcc, 0xffee };
Ask the right question, if you'd asked the question you have in the comments we'd have got there a lot quicker.

Answer 4

Here's a concrete example that should avoid any undefined behavior due to strict aliasing / "illegal" casts / etc., since this seems to be what you're actually interested in.
This code takes a std::uint64_t, copies it into an array of four std::uint16_ts, modifies the values in the array, and then copies them back into the original std::uint64_t.
#include <cstdint>
#include <cstring>
#include <iostream>
int main() {
std::uint64_t data = 0xffeeddccbbaa5577;
std::uint16_t data_spliced[4];
std::memcpy(&data_spliced, &data, sizeof(data));
std::cout << "Original data:\n" << data << "\nOriginal, spliced data:\n";
for (const auto spliced_value : data_spliced) {
std::cout << spliced_value << " ";
}
std::cout << "\n\n";
data_spliced[2] = 0xd00d;
memcpy(&data, &data_spliced, sizeof(data));
std::cout << "Modified data:\n" << data << "\nModified, spliced data:\n";
for (const auto spliced_value : data_spliced) {
std::cout << spliced_value << " ";
}
std::cout << '\n';
}
With output (on my machine):
Original data:
18441921395520329079
Original, spliced data:
21879 48042 56780 65518
Modified data:
18441906281530414455
Modified, spliced data:
21879 48042 53261 65518

Answer 5

You need to take the address of that variable if you want to assign it to a pointer
const uint16_t* vector = reinterpret_cast<const uint16_t*>( &data ) ;
NOTE:
This works on MSVC 2017, but...
This is a truck load of undefined behaviour! – Bathsheba
As cpprefrence for reinterpret_cast says:
5) Any pointer to object of type T1 can be converted to pointer to object of another type cv T2. This is exactly equivalent to static_cast<cv T2*>(static_cast<cv void*>(expression)) (which implies that if T2's alignment requirement is not stricter than T1's, the value of the pointer does not change and conversion of the resulting pointer back to its original type yields the original value). In any case, the resulting pointer may only be dereferenced safely if allowed by the type aliasing rules (see below)
...
Type aliasing.
Whenever an attempt is made to read or modify the stored value of an object of type DynamicType through a glvalue of type AliasedType, the behavior is undefined unless one of the following is true:
AliasedType and DynamicType are similar.
AliasedType is the
(possibly cv-qualified) signed or unsigned variant of DynamicType.
AliasedType is std::byte (since C++17), char, or unsigned char: this
permits examination of the object representation of any object as an
array of bytes.
Note that many C++ compilers relax this rule, as a non-standard language extension, to allow wrong-type access through the inactive member of a union (such access is not undefined in C)
The above code does not fulfill any of the Aliasing rules.