将 `int*` 转换为指向 bitset 的指针时会发生什么

Question

I am doing a simple test, calculating the number of 1's in a number's binary representation:

  int x;
  while (cin >> x) {
      bitset<32> xBitmap = {0};
      xBitmap = static_cast<bitset<32>>(x);
      std::cout << xBitmap.count() << std::endl;
  }

The above code creates the right result, but when I use a pointer to a bitset, something unexpected happens:

      bitset<32>* xBitmap = nullptr;
      xBitmap = static_cast<bitset<32>*>((void*)&x);
      std::cout << xBitmap->count() << std::endl;

This code creates random results, every use of "count()" creates a different result. I am guessing this is a memory leak? But why would it cause a memory leak?

Answer 1

What is happening in your first example?

You have a variable of type int and you perform a static_cast to convert the int to a std::bitset<32> . From the specification of static_cast ( link ):

static_cast<new_type>(expression)

1. If there is an implicit conversion sequence from expression to new_type , or if overload resolution for a direct initialization of an object or reference of type new_type from expression would find at least one viable function, then static_cast<new_type>(expression) returns the imaginary variable Temp initialized as if by new_type Temp(expression); , which may involve implicit conversions, a call to the constructor of new_type or a call to a user-defined conversion operator.

...

Consider the following example:

#include <iostream>

class A {
public:
  A(int x) { std::cout << "A " << x << std::endl; }
};

int main(void) {
  int y = 13;
  A a = static_cast<A>(y);
}

Running this program will print A 13 . This means that in this case A a = static_cast<A>(y) is equivalent to A a = A(y) . This is because y is of type int and there is a constructor for A that takes an int .

If we would change the example so that the constructor for A takes an std::string , the program would no longer compile:

#include <iostream>
#include <string>

class A {
public:
  A(std::string x) { std::cout << "A " << x << std::endl; }
};

int main(void) {
  int y = 13;
  A a = static_cast<A>(y);
}

The compiler would complain about being unable to convert an int to A .

Consider a third example:

#include <iostream>

class A {
public:
  A(int x) { std::cout << "A " << x << std::endl; }
};

class B {
public:
  B(A a) { std::cout << "B" << std::endl; }
};

int main(void) {
  int y = 13;
  B b = static_cast<B>(y);
}

This example compiles and prints:

A 13
B

So this would be what the specification calls an "implicit conversion sequence". While there is no constructor for B that takes an int , there is a constructor for B that takes an A and then there is a constructor for A that takes an int . So static_cast<B>(y) would resolve to to B(A(x)) . If we would add the explicit keyword to the constructor for A , then the example would no longer compile:

  explicit A(int x) { std::cout << "A " << x << std::endl; }

This is because the explicit keyword on a constructor forbids the constructor from being used in a implicit conversion sequence.

These examples allow us to understand what is happening when we call static_cast<std::bitset<32>>(x) . The std::bitset<N> class has a constructor that takes an unsigned long ( reference ). The constructor is not marked with the explicit keyword, so it can participate in an implicit conversion sequence. An int can be implicitly converted to an unsigned long . So static_cast<std::bitset<32>>(x) resolves to std::bitset<32>((unsigned long)x)) , so it creates a new instance of std::bitset<32> with the value of x passed to the constructor.

This is why your first example works.

What is happening in your second example?

You have a variable of type int . You create a pointer to this variable ( &x ) and then you cast the pointer to a void pointer. Then you static_cast the void pointer to a std::bitset<32> pointer. From the specification of static_cast ( link ):

10. A prvalue of type pointer to void (possibly cv-qualified) can be converted to pointer to any object type.

So unlike your first example, your second example will not create a new instance of std::bitmap<32> . Rather, xBitmap points to the memory address of x , but interprets this memory as an std::bitmap<32> . However, there is a problem with that: The memory size of a std::bitmap<32> may not be equal to the memory size of an int . This is implementation-specific, so different implementations of the C++ standard library may have different sizes for std::bitmap<32> .

On my system, using the C++ standard library that comes with GCC, the following code will print 8 :

std::cout << sizeof(std::bitset<32>) << std::endl;

This means that a std::bitset<32> takes 8 bytes of memory. While the 32 bit could of course be represented by only 4 bytes, it seems that on my system the std::bitset will always allocate multiples of 8 bytes (ie unsigned long). So for example sizeof(std::bitset<1>) is also 8 , and so is sizeof(std::bitset<64>) , but then sizeof(std::bitset<65>) is 16 and so is sizeof(std::bitset<128>) , but then sizeof(std::bitset<129>) is 24 and so on.

Whereas (on my system), an int takes only four bytes. So when we take the memory of an int but interpret it as std::bitmap<32> , we would read 8 bytes (the size of an std::bitmap<32> ) from a memory allocation that is only of size 4 bytes. So we would read an additional four bytes after the memory of the int . There could be anything in this memory, so the read results in undefined behavior. This is why you get the random values when you call count() . It will count the number of bits in the int , but also the number of bits in the four bytes after that.

Modern compilers such as GCC and Clang have a feature called "Address Sanitization" ( ASan ), which can help you debug such memory issues. For GCC, it can be enabled with the -fsanitize=address flag:

$ g++ -fsanitize=address test.cpp
$ ./a.out
123
=================================================================
==16616==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd1c7c5f80 at pc 0x55b34fd334b3 bp 0x7ffd1c7c5f00 sp 0x7ffd1c7c5ef0
READ of size 8 at 0x7ffd1c7c5f80 thread T0

So in this case, address sanitization detects that your program attempts to read past the size of an allocation.

So with regards to the part of your question about memory leaks: This is not a memory leak, but a buffer overflow. A memory leak would be when you allocate memory and then forget to free the memory.