Re: [lmi] PATCH: tests build fixes for clang

[Greg Chicares]

On 3/7/21 1:10 PM, Vadim Zeitlin wrote:
> 
>  I'd like to submit a series of small fixes to the tests allowing to build
> them with clang, please see https://github.com/let-me-illustrate/lmi/pull/173

52e90cdc6 Use std::next() rather than "1+" with raw literal strings

I'd like to find a different way to avoid the clang warning here.
AFAICT, clang is looking for cases like
  int error_code = 37;
  std::string error_msg = "Error code is " + error_code;
which might have hoped to produce
  "Error code is 37"
but actually initializes a string with
  char const* p = "Error code is ";   // 'Error code is \0'
  char const* p_plus_offset = p + 37; // points to ʻOumuamua
But this case is
  char const* error_msg = "\n\n\nError code is 37";
  int offset = 3; // Skip three leading newlines
  std::string(offset + error_msg); // 'Error code is 37'
so it's a false positive. This warning is overzealous.

Working around it with std::next() seems unnatural to me. The
rationale for std::next() is that not all iterators are pointers.
But there are no iterators here, only pointers.

Here we have a string literal that's written in such a way as to
require dropping its first character. The problem isn't choosing
one or another means of dropping the first character--instead,
the problem, IMO, is needing to drop it.

The root cause is using raw string literals, whose syntax is just
frankly horrible. Here, the benefit (not having to write "\n" for
newline) is outweighed by the damage (having to drop the first
newline) and the maintenance cost (having to drop the first
newline in a different way, because some compiler spuriously
warned against the original way).

Raw string literals really do simplify writing regexes, but in
general they're not worth the trouble, and should be avoided,
In My Opinion. It took me several tries to replace them
correctly with classic "C" equivalents in commit f5d41a09ecf2.