Patch prefix 'L' on unevaluated string literal having no effect causing an Error

[snw7]

Description

Patch prefix 'L' on unevaluated string literal having no effect causing a Warning/Errors depending on build flags.

Testing

No new tests should be required.

Documentation

This change should not require an update of the documentation.

[codecov[bot]]

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 86.28%. Comparing base (bb17196) to head (88b1edb). :warning: Report is 143 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5123      +/-   ##
==========================================
+ Coverage   85.93%   86.28%   +0.34%     
==========================================
  Files          59       59              
  Lines       18048    18048              
==========================================
+ Hits        15510    15572      +62     
+ Misses       2538     2476      -62     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

• :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[guhetier]

Hi! Sorry for the delay. Could you please clarify what was the issue with "L" prefixes? I don't see it used with CXPLAT_STATIC_ASSERT at any point. Is the problem that certain compilation options have static_assert expect a "L" prefixed string?

[snw7]

Hi! Sorry for the delay. Could you please clarify what was the issue with "L" prefixes? I don't see it used with CXPLAT_STATIC_ASSERT at any point. Is the problem that certain compilation options have static_assert expect a "L" prefixed string?

Hi Guillaume! Thanks for following up! The L prefix is required because, under certain compiler configurations (for example, when UNICODE is defined), the string literal used in static_assert is expected to be a wide string. Without the L prefix, the build fails on the toolchains due to a type mismatch in the diagnostic message literal. Adding the prefix ensures the assertion compiles consistently across all supported build configurations and avoids failures on some platforms. I initially encountered the issues on my debian server distro :-)

[guhetier]

Thanks for confirming, and for the contribution!