cancel
Showing results for 
Search instead for 
Did you mean: 

empty Map<uint64_t, shared_ptr<CLASS>>. begin() returns NULL

M.Holch
Associate II

Hello

I'm lost.. my code gets HARD-HANDLE due to illegal access, have traced it down to my MAP.

but have NO clue to why :(

My code have a map of shared pointers. with a key uint64_t.

A loop of the elements before any is added makes it crash.

now i can see the .begin() on my empty maps return NULL, WTF. I would not expect this to ever happen ?

The MAP looks to be created correct, and both left & right is set to "END"

but when using the begin(), it still return NULL

Now comes the wierd part... if i use uint32_t as key... it works :tired_face: and begin & end both return "end"

This is a reduced version in normal "c++"

my result on my STM32 is:

it32_1 : 0x24004700

it32_2 : 0x24004700

it64_1 : 0x0

it64_2 : 0x240046e5

cpp.sh/8mruw

// map::begin/end
#include <iostream>
#include <map>
#include <memory>
 
class test
{
public:
  test(){};
  ~test(){};
};
 
int main ()
{
  std::map<uint32_t, std::shared_ptr<test>> testMap32;
  std::map<uint64_t, std::shared_ptr<test>> testMap64;
    
  auto it32_1 = testMap32.begin();
  auto it32_2 = testMap32.end();
 
  auto it64_1 = testMap64.begin();
  auto it64_2 = testMap64.end();
  
  printf("it32_1 : %p\r\n",it32_1);
  printf("it32_2 : %p\r\n",it32_2);
 
  printf("it64_1 : %p\r\n",it64_1);
  printf("it64_2 : %p\r\n",it64_2);
 
  return 0;
}

Is this a BUG in the compiler ???

I have updated to IDE 1.7

Update:

using key:

uint8_t Fails

uint16_t Success

4 REPLIES 4
Pavel A.
Evangelist III

Where is your heap? Do you know that 0 is a valid RAM address on some STM32s ?

It's unclear what printf %p does with an iterator passed as an argument. An iterator is not a pointer, and you can't dereference the end iterator. If that's not it, the only explanation I can think of is a failed and unhandled memory allocation which makes its way back as a nullptr.

Does the comparison it32_1 == it32_2 succeed? And how about it64_1 == it64_2?

In this instance, even if 0 is a valid memory address, it's still wrong as end() and begin() should be identical for an empty container. But again, it's unclear what is actually being printed here.

Edit: this was meant to be a top-level post, not a reply.

If you feel a post has answered your question, please click "Accept as Solution".

compare Test returns TRUE for 32bit IT compare.. and FALSE for the 64bit IT compare...

TDK
Guru

Seems like a bug to me. Pass it on to the GCC folks.

https://gcc.gnu.org/bugs/

You could also check to see if there's an updated toolchain available.

If you feel a post has answered your question, please click "Accept as Solution".