C++ SampleMutUninit payload operator: error: taking address of rvalue

[PeakKS]

Required information

Operating system:
Ubuntu 24.04.3 LTS
Linux GLDLBAE00056713 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Rust version:
rustc 1.90.0 (1159e78c4 2025-09-14)

Cargo version:
cargo 1.90.0 (840b83a10 2025-07-30)

iceoryx2 version:
v0.7.0

clang version:
Ubuntu clang version 20.1.8 (++20250804090239+87f0227cb601-1~exp1~20250804210352.139)

gcc version:
gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0

c++ std:
c++20

Detailed log output:
Clang does not complain. GCC does complain, though it can be supressed with -fpermissive.

/home/blake/.conan2/p/b/iceor64e5d76a8f489/p/include/iceoryx2/v0.7.0/iox2/sample_mut_uninit.hpp:124:24: error: taking address of rvalue [-fpermissive]
  124 |     return &payload_mut();
      |             ~~~~~~~~~~~^~

Observed result or behaviour:
At optimization level -O2 or above, this causes runtime crashes under clang. GCC requires -fpermissive to allow this to compile, when doing so it will crash on (all?) optimization levels.

Expected result or behaviour:
Not crashing.

Conditions where it occurred / Performed steps:
Create a sample and try to access it's payload, the program will segfault. Example:

auto sample = publisher.loan_slice_uninit( messageWords * sizeof( capnp::word ) ).expect( "accquire sample" );
SPDLOG_INFO("Payload bytes: {}", sample->number_of_bytes());

By changing the above to explicitly retrieve the payload from the sample, the crash is fixed and the code works as expected.

auto sample = publisher.loan_slice_uninit( messageWords * sizeof( capnp::word ) ).expect( "accquire sample" );
auto payload = sample.payload_mut();
SPDLOG_INFO("Payload bytes: {}", payload.number_of_bytes());

I would assume this same issue might appear in other places as well, but I haven't checked myself.

[PeakKS]

On this note I also find these convenience operators really messy, objects that have both .has_value and ->has_value gets confusing fast and negates rust safety just to save a few characters.

[elfenpiff]

@PeakKS Thanks for the bug report!

On this note I also find these convenience operators really messy, objects that have both .has_value and ->has_value gets confusing fast and negates rust safety just to save a few characters.

You have a point here and I agree, maybe we should just remove them to have also a more consistent and explicit look and feel.

Lets do it quick vote on that. Who would be in favor of removing operator*() and operator->() from Sample, SampleMut, RequestMut, ActiveRequest, ResponseMut, Response

@elBoberido @FerdinandSpitzschnueffler @orecham @dkroenke @ComicSansMS

[elBoberido]

@elfenpiff how exactly would this affect the API? Obviously, these operators would be gone, but how does the alternative access look like? The OP was asking only about .has_value and ->has_value. I guess the second one is just the arrow operator delegating to the has_value of the underlying type.

[elfenpiff]

@elBoberido The API change:

// old
sample->some_member;
*sample = 123;

// new
sample.payload().some_member;
sample.payload() = 123;

[elBoberido]

@elfenpiff okay. It is more verbose but also unambiguous. We break the API, though. On the other hand -> #1058 (comment)