<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jul 3, 2022 at 10:59 PM Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.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">> On Jul 3, 2022, at 4:47 AM, Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>> wrote:<br>
> <br>
> I am preparing a patch to forbid C-heap allocation functions in hotspot as you proposed (<a href="https://github.com/openjdk/jdk/pull/9356" rel="noreferrer" target="_blank">https://github.com/openjdk/jdk/pull/9356</a>). <br>
> <br>
> Interestingly, not all occurrences of forbidden functions are found everywhere. I found that if I compile on Ubuntu 20.04 with gcc 10.3., it does not complain about "realpath" even though I forbade it. If I build on Alpine, gcc 10.3.1, it finds occurrences of realpath.<br>
<br>
In which build variants?  All?  Or only fastdebug?  If the latter, this might be another case of<br>
_FORTIFY_SOURCE rewriting the call first, dodging the warning.  This is mentioned in the<br>
comment describing the gcc implementation of FORBID_C_FUNCTION.<br>
<br></blockquote><div><br></div><div>No, it fails also on release to recognize realpath. Just to be sure I tested the most important other candidates (malloc, free, realloc, calloc, strdup) and those all work.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Note also that I didn’t find a way to provide this feature for Windows/VisualStudio, and the<br>
clang implementation didn’t get tested by me.  (Oracle only uses clang when building for<br>
MacOS using Xcode, and no released version of Xcode has a sufficiently recent version<br>
of clang to have the needed feature set.)<br>
<br></blockquote><div><br></div><div>One thing that I dislike is that this requires including globalDefinitions.hpp. Not every cpp or hpp file may include that. Also, since in theory, to have 100% coverage, every file and header should include globalDefinitions.hpp, we may want to move these macros into an own file to avoid blowing up the dependencies.</div><div><br></div><div>But other than that, I like this mechanism. Its very practical.</div><div><br></div><div>Cheers, Thomas</div></div></div>