RFR: 8255416: Investigate err_msg to detect unnecessary uses [v3]

[Aleksey Shipilev]

On Thu, 29 Oct 2020 08:20:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Actually, this code prevents a single string argument in compile time. It relies on two constructors to introduce ambiguity in overload resolution that makes C++ compiler complain and abort compilation. Comment above the dummy constructor should clarify that for anyone stepping on compile error.
>>   inline FormatErrBuffer(const char* format, ...) ATTRIBUTE_PRINTF(2, 3);
>>   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
>> For sanity check, I've used this sample code https://godbolt.org/z/szs6rE
>> 
>> And the cases that were fixed have been detected by the compiler.
>> 
>> I don't think that this problem is a serious issue as well. But as for me, it is a minor code complexity increase to ensure that the minor problem of extra string copy will never appear again.
>
> Oh, now I see it. Smart.
> 
> But it occurred to me that someone may want to start a err_msg buffer up with a string literal, only to then add additional content via FormatBuffer::append(). So initializing it with a literal and no arguments may be a valid usecase. 
> 
> So I'd still prefer keeping this out. Alternatively, if you like to keep it in, could we just not implement the second constructor? Which should give us linker errors if the static check fails.

+1 to leave this undefined to get a linkage error. There are already precedents to do this in Hotspot code, for example

  Node(const Node&);            // not defined; linker error to use these
  ...
  // should never be used
  AdapterHandlerEntry();

-------------

PR: https://git.openjdk.java.net/jdk/pull/905