Remove dst_size from strnlen usage

[Blast545]

Attempt to address #352

There's already a comparison to get the min value from dest_size and src_length here:

rcutils/src/error_handling_helpers.h

Line 60 in befc608

if (src_length >= dst_size) {

So I just removed the dst_size from the calculation of the source size.

Signed-off-by: Jorge Perez jjperez@ekumenlabs.com

[Blast545]

Reproducing the warning, up-to rcutils:

Testing with this PR:

[Blast545]

Removing ros1_bridge from the packaging test job:

Removing ros1_bridge and testing with this PR:

[Blast545]

Let me know if you think this fix is OK before running full CI @clalancette

[clalancette]

This seems reasonable to me; there is really no reason that we should use strnlen(src, dst_size), since src and dst_size are not correlated at all.

That said, I'll be interested to see what happens when we run CI on this on all platforms, because some of them may complain about using a "bare" strlen. Besides the normal CI (Linux, Linux aarch64, Windows), I'll suggest also running CI with Windows Debug, the clang job, and RHEL to see if anything complains.

[clalancette]

Full CI on this change:

• Linux
• Linux-aarch64
• Windows
• Windows Debug
• Linux Clang
• RHEL
• Packaging Linux
• Packaging Linux aarch64
• Packaging Windows

[clalancette]

All right, running through CI results here:

• Linux-aarch64 is unstable, but that is happening on the nightlies as well and is due to a bug in Eigen
• Windows Debug is unstable; most of the tests there are failing in the nightlies as well, except for the test_action_client_server__rclpy__rmw_fastrtps_cpp
• Linux Clang is failing, but that is failing on the nightlies as well. Update to curl 7.81. ros/resource_retriever#74 improves (though does not completely fix) the situation.
• RHEL looks to be about the same as the nightlies
• Packaging Linux looks to be about the same as the nightlies, minus one additional warning
• Ditto for Packaging Linux aarch64

So with all of that, the only "new" thing here is the one failure on Windows Debug. I'm going to rerun that one to see if it is a flake:

• Windows Debug

[clalancette]

All right, Windows Debug is much happier on the latest round. I'm going to go ahead and merge this one in, thanks @Blast545 !