feat: extend API with ptr/len-string interfaces

[supervacuus]

Fixes #819.

[github-actions]

	Messages
📖	Do not forget to update Sentry-docs with your feature once the pull request gets approved.

Generated by 🚫 dangerJS against 5a4664a

[codecov]

Codecov Report

Merging #827 (2b3a5f6) into master (1788653) will increase coverage by 1.37%.
The diff coverage is 76.71%.

❗ Current head 2b3a5f6 differs from pull request most recent head 16c8c30. Consider uploading reports for the commit 16c8c30 to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #827      +/-   ##
==========================================
+ Coverage   81.20%   82.57%   +1.37%     
==========================================
  Files          53       53              
  Lines        6981     7301     +320     
  Branches     1119     1179      +60     
==========================================
+ Hits         5669     6029     +360     
+ Misses       1201     1165      -36     
+ Partials      111      107       -4     

[supervacuus]

Hi @Swatinem, can you give this a first once-over when you have time? (it is not urgent because I am unsure if I will have time to continue working on the PR before the easter holidays).

What the PR should do is rather apparent, but I was experimenting with how to de-duplicate the two paths in the code base. Sometimes the most trivial approach is to stay with two separate implementations (if the line count is low). Sometimes, it makes sense to express one in terms of the other. Sometimes I felt it would make the most sense to create a macro where parameters and parameter-dependent function calls are parameterized.

When implementing one in terms of the other, I typically wrote the c-string interface in terms of the byte-string one because you only pay for an additional NULL-check and strlen(), which you'd have to do anyway later on if you don't end up in an error branch, vs. potentially paying double for allocation.

Could you tell me whether the macros make sense and whether you have different implementation favorites for those instances? The PR is incomplete; I want to add even more unit tests (some of the previous functions were "covered" but not tested, revealing a few places that led to NULL-induced access violations). I also haven't yet touched the windows-specific interfaces.

Thx!

[supervacuus]

Also fixes: #831

[supervacuus]

The remaining macOS CI build also fails on master: https://github.com/getsentry/sentry-native/actions/runs/4542271760/jobs/8420339196; last week, the macOS 11 image was updated. Of course, that doesn't mean there is no leak in the code, just that a change in this PR didn't introduce it.

I could not repro the leak using leaks on macOS, and the LLVM ASAN for aarch64 has some issues. But I will investigate further. Otherwise, I am open to any review suggestions :-)

[supervacuus]

haha, what? https://github.com/getsentry/sentry-native/actions/runs/4742464992/jobs/8420773714?pr=827 🤦

[supervacuus]

haha, what? https://github.com/getsentry/sentry-native/actions/runs/4742464992/jobs/8420773714?pr=827 🤦

The previous CI run from 1h ago still used the image version 20230411.1 (from last week), whereas this one used 20230318.1 (from yesterday? last month). Not all runners get the latest same, though, as this re-run on master shows: https://github.com/getsentry/sentry-native/actions/runs/4542271760/jobs/8421381133.

🤷 something, something eventual consistency. I err on the "this is not a real leak side".

[markushi]

Nice one, please have a look at my comments!

[supervacuus]

LSAN correctly found a leak, but it is outside our control:

• our build on CI picks up the libcurl library of the MacOSX 12.1 SDK from XCode 13.2.1, which has version 7.77.0,
• the following fix was provided in 7.78.0
• which rectifies a leak introduced by a feature that was introduced with 7.77.0 (i.e., our version)

It is unclear why the build suddenly broke with the new runner images because neither XCode/SDK (and its libcurl version) nor llvm/clang/lsan where updated from previous builds.