Fix chunkHeader==nullptr in allocateChunk

[evshary]

allocateChunk should return nullptr if chunkHeader==nullptr, or it might cause some problem in returning chunkHeader->payload() and user can't check whether allocate chunk successfully or not.

[budrus]

Thanks @evshary . This makes sense.
Internally we switched more to our expected and optional data types in such method return values. We will change the public API with #25 anyway. I'm wondering if we should use this more modern C++ API style also on the top API level. Like here https://github.com/budrus/iceoryx/blob/iox-%2325-chunk-receiver-building-block/iceoryx_posh/include/iceoryx_posh/internal/popo/building_blocks/chunk_sender.hpp#L60

What do you think @evshary @mossmaurice @elBoberido @elfenpiff

[budrus]

@evshary: Can you please change the target branch to staging, as described in https://github.com/eclipse/iceoryx/blob/master/CONTRIBUTING.md

[evshary]

@evshary: Can you please change the target branch to staging, as described in https://github.com/eclipse/iceoryx/blob/master/CONTRIBUTING.md

@budrus I guess I make something wrong. Should I rebase this fix to staging branch and then PR?

[budrus]

@evshary: Can you please change the target branch to staging, as described in https://github.com/eclipse/iceoryx/blob/master/CONTRIBUTING.md

@budrus I guess I make something wrong. Should I rebase this fix to staging branch and then PR?

@evshary Sorry, I will rebase staging, Just a second

[budrus]

@evshary: Can you please change the target branch to staging, as described in https://github.com/eclipse/iceoryx/blob/master/CONTRIBUTING.md

@budrus I guess I make something wrong. Should I rebase this fix to staging branch and then PR?

@evshary Sorry, I will rebase staging, Just a second

@evshary . Sorry again, can you switch back to master as target. The staging branch got the same restrictions as master from Eclipse. As I don't have the reviewers now, I cannot update the staging branch. We have to figure out how we can manage the staging branch step in future

[evshary]

@evshary: Can you please change the target branch to staging, as described in https://github.com/eclipse/iceoryx/blob/master/CONTRIBUTING.md

@budrus I guess I make something wrong. Should I rebase this fix to staging branch and then PR?

@evshary Sorry, I will rebase staging, Just a second

@evshary . Sorry again, can you switch back to master as target. The staging branch got the same restrictions as master from Eclipse. As I don't have the reviewers now, I cannot update the staging branch. We have to figure out how we can manage the staging branch step in future

Sure.

[elBoberido]

Thanks @evshary . This makes sense.
Internally we switched more to our expected and optional data types in such method return values. We will change the public API with #25 anyway. I'm wondering if we should use this more modern C++ API style also on the top API level. Like here https://github.com/budrus/iceoryx/blob/iox-%2325-chunk-receiver-building-block/iceoryx_posh/include/iceoryx_posh/internal/popo/building_blocks/chunk_sender.hpp#L60

What do you think @evshary @mossmaurice @elBoberido @elfenpiff

I think we need to decide which type of API we want to have, a type safe C++ API or a lowlevel C-ish API? There a pros and cons for both of them. Personally I wouldn't go the C-ish API since it's to C++ to easily create language bindings and to C to make it type safe.
I think we should probably support a modern C++ API and a C API, one as default and the other one as official binding.