<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le dim. 11 nov. 2018 à 10:25, Louis Dionne <<a href="mailto:ldionne@apple.com">ldionne@apple.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Nov 11, 2018, at 00:08, Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="gmail-m_-1530529109102170116Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br class="gmail-m_-1530529109102170116Apple-interchange-newline">On Nov 10, 2018, at 23:14, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:<br><br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="ltr"><div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">Le mar. 30 oct. 2018 à 15:57, Louis Dionne via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Oct 30, 2018, at 18:00, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div><br class="gmail-m_-1530529109102170116m_2573678037745819625Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Awesome!<br><br>What are the new semantics? That this ABI stability guarantee is provided by hiding the functions in each user so they can't be deduplicated with anotehr user's copy? (what about other copies that are from the same build? I guess even those won't get coalesced/collapsed together? Would that be useful to support?)<br></div></div></blockquote><div><br></div><div>There are currently two modes (in LLVM trunk, and that is the plan for LLVM 8 too):</div><div><br></div><div>1. (the default) All TUs linked together inside the same final linked image need to have use the same libc++ version. Inline functions are ODR-merged across TUs like they normally are. In this mode, we don't use any funny attribute to control linkage (neither always_inline nor internal_linkage).</div><div><br></div><div>2. (can be opted-in) TUs can be linked together even if they use different headers of libc++. This is achieved by using internal_linkage on implementation detail functions of libc++. Those functions are local to a TU and they are NOT ODR-merge across TUs. This results in more code duplication than option (1).</div><div><br></div><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br>I assume this doesn't change the defaults, but does it make it any easier for users who don't need the ABI stability guarantee? (or was it already easy/no change here?)<br></div></div></blockquote><div><br></div><div>It actually does change the default. However, it depends of what ABI guarantee you're talking about.</div><div><br></div><div>1. The ABI stability of the shared objects is always (and has always been, and will most likely always) be guaranteed. The only way to change that is to explicitly use the _LIBCPP_ABI_UNSTABLE macro, which says "use all the ABI breaking features". This obviously only works if you're also linking against a library that was built to provide that ABI. This ability to use the unstable ABI has been provided for a long time, it wasn't the default, and it still isn't the default -- my change is completely orthogonal to that.</div><div><br></div><div>2. The "ABI stability" of static archives is a different matter. The question here is whether you can link programs against static archives built with different versions of libc++. The answer used to be YES by default, not it is NO by default. If you want to retain that ability, you need to use the `_LIBCPP_HIDE_FROM_ABI_PER_TU` macro. And also please give us a heads up so we know someone is using it.</div></div></div></blockquote><div><br></div><div>In general I'm worried of "undefined behavior" that isn't caught by a tool, ideally at build time otherwise at runtime. I would really encourage to not introduce any default behavior where you can't provide an easy detection mechanism to the user.</div></div></div></div></blockquote><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Can you please expand on what you mean here? Are you referring to the potential for ODR violations if someone links TUs built against different versions of the libc++ headers? If so, that situation exists for every single C++ library out in the wild.</div></div></blockquote></div></div></blockquote><div>When you provide a system library / core components, you can (should) hold higher standard than other convenience library that the user opt in in my opinion.</div><div>Also the "the others aren't better" seems to me like a fairly lame excuse.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>More specifically, what I mean here is that anyone relying on this guarantee is walking an incredibly thin line</div></div></blockquote><div><br></div><div>I don't know what you mean here.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><div>, and so I think it is reasonable for such users to explicitly opt into the guarantee.</div></div></blockquote><div><br></div><div>You're missing the point: as a user building my application / libraries using Xcode for instance, I am not aware of what guarantee the compiler provides in this kind of area. This is incredibly subtle. How do I know what I need to know to "opt into the guarantee"?</div><div>This is not much different than undefined behavior in the language (expect less documented and more arcane), and we learned with time that dealing with undefined behavior for the average user is incredibly difficult. </div><div><br></div><div>So back to the point: safety and usability should come first when you supply libraries and tools to users. This is on the same line as an "API should be easy to use and hard to misuse". If you don't have an easy way to find/detect the problem that you can widespread as part of your environment/tools, then you created an "API that is too easy to misuse". </div><div>(I know this is not really an API discussion here, but that's not much different: this is a contract with a client).</div><div><br></div><div>I argue that whenever we're introducing such behavior, we're not delivering a good user experience.</div><div><br></div><div>I think that Chandler presented good foundations to approach this at CppCon 2016 in the talk “Garbage In, Garbage Out: Arguing about Undefined Behavior...": <a href="https://www.youtube.com/watch?v=yG1OZ69H_-o">https://www.youtube.com/watch?v=yG1OZ69H_-o</a></div><div><br></div><div>Especially, since we're going from a "wider" to a "narrower" contract here, this slide is particularly relevant and represent the concern I raised: <a href="https://youtu.be/yG1OZ69H_-o?t=1279">https://youtu.be/yG1OZ69H_-o?t=1279</a></div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div></div></div></div></div></div></div>