-4

I have a void* lhs_value pointing to a sufficiently sized mallocated region of memory. I want to save a rvalue of type bool into it. Don't ask me why I wanted that. I think that this is as simple as casting that pointer to bool* and de referencing it. However the compiler complains. I am apparently doing something wrong. Can you help me with this?

 error: expected '(' for function-style cast or type construction
                *((*bool) lhs_value) = true;
void* lhs_value;
lhs_value = malloc( sizeof(int) );
memset(lhs_value, 0, sizeof(int));
*((*bool) lhs_value) = true;
Galaxy
  • 2,363
  • 2
  • 25
  • 59
  • show us some code –  Jun 01 '19 at 22:36
  • @0x476f72616e I am showing that single line of code where I attempt to save `true` into the memory location pointed to by `lhs_value`. What else code do you want me to show? – Galaxy Jun 01 '19 at 22:37
  • 1
    Just hint: can you declare `*bool value;`? – R2RT Jun 01 '19 at 22:42
  • @R2RT Upon certain circumstances, I may also be saving `short` and `int` values into this memory location. – Galaxy Jun 01 '19 at 22:43
  • Note the position of `*`. I phrased it badly: Is `*bool value;` valid C++ code? – R2RT Jun 01 '19 at 22:43
  • 2
    You've placed one of the `*` in the wrong place. `(*bool)` doesn't make sense where you have it. `(bool *)` will work. Voting to close as this is essentially a typo. – Peter Jun 01 '19 at 22:53
  • 1
    @Peter How in the world did I not notice that? – Galaxy Jun 01 '19 at 23:12
  • 3
    Typos are like that. Easy to do, the person who does them has trouble spotting them, easily spotted by someone else. (Also, after time is passed, the person who made a typo can often see it easily too). Similar thing happens in essays, books and journal articles all the time - someone writes something, when reading what they wrote they see what they intended to write rather than what they actually wrote. Technically it's a form of cognitive bias that inflicts most humans. – Peter Jun 01 '19 at 23:29

2 Answers2

4

There's only one way to type pun correctly in C++:

#include <cstring>

bool value = true;
std::memcpy(lhs_value, &value, sizeof value);  // ::memcpy also ok
                                               // in which case #include <string.h>

Unions are not correct and pointer casts are not correct (although the pointer cast will work on a pointer returned directly from an allocation function, it is not required to work on all void* values to valid memory).

(Yes, you should have allocated memory in advance. Use malloc only if you are passing the pointer to a C library which will call free() on it. Otherwise use a proper C++ allocator like ::operator new(). lhs_value = new bool(true) is best of all, if you can cast back to the original type (bool*) when using the delete operator. No, you should not intermix sizeof (bool) with sizeof (int) unless you test it is sufficient -- sizeof (char) == 1 always but no guarantees on other built-in types. No, you do not need to call memset.)

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
3
   *static_cast<bool*>(lhs_value) = true;

be aware of aliasing rules before doing this; they are complex and hard to get right, and the symptom of getting them wrong is "the code works" until it breaks in a random way in a random spot after a compiler upgrade.

Michi
  • 681
  • 1
  • 7
  • 25
Yakk - Adam Nevraumont
  • 262,606
  • 27
  • 330
  • 524
  • 1
    Is `static_cast` better/safer than `reinterpret_cast` in this case? I have no argument either way. It just _felt_ like a `reinterpret_cast` case to me so I have to ask. – Ted Lyngmo Jun 01 '19 at 23:05
  • 3
    @TedLyngmo: `reinterpret_cast` is defined as "static_cast to `void*`, static_cast that result to the destination type". Here is input is already `void*`. – Ben Voigt Jun 02 '19 at 00:56
  • 1
    @tedl so, reinterpret casts should be massive red flags in your code. Static casting a void pointer, meanwhile, is less so; all void pointers are for is being cast out of. It is no more a red flag than the `void*` was... – Yakk - Adam Nevraumont Jun 02 '19 at 04:12
  • Thanks @Yakk-AdamNevraumont - I'll keep that in mind! – Ted Lyngmo Jun 02 '19 at 06:32