<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Neither the docs nor the review seem to explain why this new special-purpose "fortify-stdlib" attribute is necessary. Were you were unaware that there's already an implementation of a fortified libc built on existing clang features, or is that existing mechanism unsatisfactory?</div><div><br></div><div>If we _do_ need a new attribute for this for some reason, then having it special-case a list of function names is quite unfortunate -- the list it supports now certainly isn't the complete list of functions that need fortified versions, and some of those functions which need fortified versions in a given libc aren't defined by any standard. Having to add support for them all into the compiler seems rather unsatisfactory.</div><div><br></div><div>So, if this new feature <i>is</i> needed for some reason, it would seem much better to make the behavior explicitly specified in the attribute, rather than special cased for a given set of known function-names. (E.g. the attribute could specify exactly what edits to make to the function call: which name to call instead, and what extra arguments to insert where into the argument list.)<br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 19, 2019 at 7:02 PM Erik Pilkington <<a href="mailto:erik.pilkington@gmail.com">erik.pilkington@gmail.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 style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Feb 19, 2019, at 3:34 PM, Reid Kleckner 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_2150529870155847824Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr">On Tue, Feb 19, 2019 at 3:15 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br></div><div class="gmail_quote"><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">If someone wishes to contribute support to glibc to better support these fortifications with clang, it should be pretty easy. Simply look at how FORTIFY_SOURCE is implemented in the Bionic libc, and do something similar to that (with appropriate ifdeffery, because that version is not going to work in GCC).</div></div></blockquote><div><br></div><div>It is unfortunate, however, that the two communities haven't settled on an agreeable set of extensions to implement this feature. I can understand why glibc wouldn't want a second parallel implementation with it's own set of bugs requiring its own tests. Getting this right really requires someone who cares about it enough to get involved in all of the relevant projects here: glibc, clang, gcc, and maybe even bionic. That sounds like a lot of work, so I understand why it hasn't been done.</div></div></div></div></blockquote><div><br></div><div>I’ve been working on improving _FORTIFY_SOURCE support for apple’s c standard library. I added the attribute fortify_stdlib (<a href="https://clang.llvm.org/docs/AttributeReference.html#fortify-stdlib" target="_blank">https://clang.llvm.org/docs/AttributeReference.html#fortify-stdlib</a>) so it should just be a matter of glibc slapping it on a few functions and clang will do the rest, which doesn’t seem like much of a burden. The narrative that clang is far behind GCC for _FORTIFY doesn’t really add up to me either, there are some clang extensions that GCC doesn’t support either, for instance: __builtin_dynamic_object_size and pass_object_size.</div><br><blockquote type="cite"><div>
_______________________________________________<br>cfe-dev mailing list<br><a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br></div></blockquote></div><br></div></blockquote></div>