nothrow not working in C++ with PSoC6

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
FirmEngineer
Level 2
Level 2
5 sign-ins First like received First solution authored

Hello,
I am converting my project to C++ and I don't want to use exceptions. I added the compiler flag "-fno-exceptions" (which is actually already used by default) and I wanted to verify that I can check for a nullptr instead of having an exception thrown. I implemented the following:

while (true) {
    void *p = operator new(100000000ul, std::nothrow);
    // int32_t* p = new (std::nothrow) int[100000000ul]; // also tried
    if (p == nullptr) {
        break;
    }
}

Unfortunately `p` never ends up being a nullptr. After the first loop, the application jumps to  Cy_SysLib_ProcessingFault while(true){} in cy_syslib.c.
So there is no way for me to manually handle this type of memory allocation error. The same code works fine when I compile with gcc for my computer. I attempted different C++ version flags too.


My setup:
Micro: CY8C6245LQI-S3D02
Tools: ModusToolbox v2.4 using both gcc 10.3.1.81 and 11.2.1
DevEnv: Ubuntu 20.04, command-line build

Any help would be much appreciated!

0 Likes
1 Solution

We downloaded and built the ARM toolchain and found that the reason a nullptr isn't being returned is because the toolchain's implementation of noexcept just calls the exception throwing version. Since exceptions are disabled, it doesn't work so it calls abort(), which is what we are seeing with our device.

34│ _GLIBCXX_WEAK_DEFINITION void *
35│ operator new (std::size_t sz, const std::nothrow_t&) noexcept
36│ {
37│ // _GLIBCXX_RESOLVE_LIB_DEFECTS
38│ // 206. operator new(size_t, nothrow) may become unlinked to ordinary
39│ // operator new if ordinary version replaced
40│ __try
41│ {
42├    return ::operator new(sz);
43│ }
44│ __catch (...)
45│ {
46│    return nullptr;
47│ }
48│ }

This undesirable behavior is unfortunately decided by ARM. The solution is for us to write our own 'new' wrapper around malloc and do the memory allocation check there.

Thanks for taking a look into this.

View solution in original post

5 Replies
AlenAn14
Moderator
Moderator
Moderator
500 replies posted 100 solutions authored 250 replies posted

Hi @FirmEngineer ,

If you want 'p' to be a null pointer, then you will have to create the pointer p using the nullptr_t as shown below

        while (true) {
       	 nullptr_t *p =nullptr;
            if (p == nullptr) {
                break;
            }
        }

 

Warm Regards
Alen



0 Likes

Hey @AlenAn14 ,

Thanks for the response. I am trying to get nothrow to work so the system doesn't throw an exception when it fails to allocate memory. You typically don't want exceptions enabled in an embedded system. A better explanation:
https://embeddedartistry.com/blog/2018/05/10/nothrow-new-the-variant-to-use-when-avoiding-c-exceptio...

0 Likes

Hi @FirmEngineer ,

I tested out your scenario and it is not working as expected on the PSoC 6 device where it is throwing a BusFault exception instead of returning the nullptr or NULL during conditions of insufficient memory.

I have created an internal ticket for this with our team to check more on as to why the same happens.

Thanks & Warm Regards
Alen

We downloaded and built the ARM toolchain and found that the reason a nullptr isn't being returned is because the toolchain's implementation of noexcept just calls the exception throwing version. Since exceptions are disabled, it doesn't work so it calls abort(), which is what we are seeing with our device.

34│ _GLIBCXX_WEAK_DEFINITION void *
35│ operator new (std::size_t sz, const std::nothrow_t&) noexcept
36│ {
37│ // _GLIBCXX_RESOLVE_LIB_DEFECTS
38│ // 206. operator new(size_t, nothrow) may become unlinked to ordinary
39│ // operator new if ordinary version replaced
40│ __try
41│ {
42├    return ::operator new(sz);
43│ }
44│ __catch (...)
45│ {
46│    return nullptr;
47│ }
48│ }

This undesirable behavior is unfortunately decided by ARM. The solution is for us to write our own 'new' wrapper around malloc and do the memory allocation check there.

Thanks for taking a look into this.

Hi @FirmEngineer ,

Glad your query is resolved and thank you for sharing the solution with the community !

Please feel free to post any queries or issues you may have on Infineon products in the community and we will be happy to help.

Warm Regards
Alen

0 Likes