<div dir="ltr">Yes, the code has been there for ages so it seems that 99.9% of the time the two string literals share storage. I'm not sure if it is a cmake change or a vs2017 change (I updated both) that caused the issue to pop up. It is a debug build with DEBUG_LEAKS turned on. But forcing them to share the same address definitely solved the problem and seems that safe approach from a standards point of view.<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 8, 2019 at 3:25 AM Julien Finet <<a href="mailto:julien.finet@kitware.com">julien.finet@kitware.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">From <a href="https://timsong-cpp.github.io/cppwp/lex.string#15" target="_blank">https://timsong-cpp.github.io/cppwp/lex.string#15</a>:<br></div><div dir="ltr">    <i>whether successive evaluations of a string-literal yield the same or a different object is unspecified  </i><br></div><div dir="ltr"><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jan 7, 2019 at 9:52 PM Elvis Stansvik <<a href="mailto:elvis.stansvik@orexplore.com" target="_blank">elvis.stansvik@orexplore.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Den mån 7 jan. 2019 kl 20:41 skrev David Cole via vtk-developers<br>
<<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>>:<br>
><br>
> Is it built with the /GF compiler flag?<br>
><br>
> <a href="https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017" rel="noreferrer" target="_blank">https://docs.microsoft.com/en-us/cpp/build/reference/gf-eliminate-duplicate-strings?view=vs-2017</a><br>
<br>
(Also note that flag is in effect when /O1 or /O2 is used)<br>
<br>
><br>
><br>
> On Mon, Jan 7, 2019 at 11:59 AM Ben Boeckel via vtk-developers<br>
> <<a href="mailto:vtk-developers@vtk.org" target="_blank">vtk-developers@vtk.org</a>> wrote:<br>
> ><br>
> > On Mon, Jan 07, 2019 at 11:39:17 -0500, Ken Martin via vtk-developers wrote:<br>
> > > On VS2017 Debug with DEBUG_LEAKS I'm seeing an odd issue. DebugLeaks is<br>
> > > complaining about vtkCommands being leaked because the two string literals<br>
> > > in the below code have different addresses (the string address is used in a<br>
> > > map type structure). Looking at DebugLeaks the only way this code would<br>
> > > work is if they have the same address. But I checked in the debugger and<br>
> > > they have different addresses.<br>
> > ><br>
> > > <snip><br>
> > ><br>
> > > I can fix it by doing the following but wanted a c++ expert to weigh in,<br>
> > > was the original code OK? Is this a compiler compliance issue? Is the<br>
> > > proposed fix the right approach?<br>
> ><br>
> > I don't think the standard says anything about a string literal with the<br>
> > same content as another literal having to share an address. I'd expect<br>
> > that this is mainly optimization at the compiler or linker level. For<br>
> > example, this:<br>
> ><br>
> >     const char* foo = "foobar";<br>
> >     const char* bar = "bar";<br>
> ><br>
> > can be satisfied with this in the resulting binary:<br>
> ><br>
> >     "foobar\0"<br>
> >      ^  ^<br>
> >      |  bar<br>
> >      foo<br>
> ><br>
> > but I'd expect the standard to say that doing `foo < bar` is always<br>
> > undefined behavior since they're not pointers to the same object.<br>
> ><br>
> > > const char *cname = "vtkCommand or subclass";<br>
> > ><br>
> > > //----------------------------------------------------------------<br>
> > > vtkCommand::vtkCommand():AbortFlag(0),PassiveObserver(0)<br>
> > > {<br>
> > > #ifdef VTK_DEBUG_LEAKS<br>
> > > vtkDebugLeaks::ConstructClass(cname);<br>
> > > #endif<br>
> > > }<br>
> > ><br>
> > > //----------------------------------------------------------------<br>
> > > void vtkCommand::UnRegister()<br>
> > > {<br>
> > > int refcount = this->GetReferenceCount()-1;<br>
> > > this->SetReferenceCount(refcount);<br>
> > > if (refcount <= 0)<br>
> > > {<br>
> > > #ifdef VTK_DEBUG_LEAKS<br>
> > > vtkDebugLeaks::DestructClass(cname);<br>
> > > #endif<br>
> > > delete this;<br>
> > > }<br>
> > > }<br>
> ><br>
> > This looks reasonable to me. Maybe add `static`?<br>
> ><br>
> > --Ben<br>
> > _______________________________________________<br>
> > Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
> ><br>
> > Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
> ><br>
> > Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
> ><br>
> > Follow this link to subscribe/unsubscribe:<br>
> > <a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
> ><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
><br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="https://vtk.org/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">https://vtk.org/mailman/listinfo/vtk-developers</a><br>
<br>
</blockquote></div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>Ken Martin PhD<div>Distinguished Engineer<br><span style="font-size:12.8px">Kitware Inc.</span><br></div><div>101 East Weaver Street<br>Carrboro, North Carolina<br>
27510 USA<br><br><div><span style="font-size:10pt;font-family:Tahoma,sans-serif">This communication,
including all attachments, contains confidential and legally privileged
information, and it is intended only for the use of the addressee.  Access to this email by anyone else is
unauthorized. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken in reliance on it is prohibited and may be
unlawful. If you received this communication in error please notify us
immediately and destroy the original message. 
Thank you.</span></div></div></div></div></div></div></div>