<div dir="ltr"><div dir="ltr">On Mon, Jul 4, 2022 at 12:46 PM Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.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">> On Jul 4, 2022, at 3:18 AM, Thomas Stüfe <<a href="mailto:thomas.stuefe@gmail.com" target="_blank">thomas.stuefe@gmail.com</a>> wrote:<br>
> On Sun, Jul 3, 2022 at 10:59 PM Kim Barrett <<a href="mailto:kim.barrett@oracle.com" target="_blank">kim.barrett@oracle.com</a>> wrote:<br>
> > 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>
> <br>
> 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.<br>
<br>
It works (fails with expected warning) for me.  gcc 11.2, in case that matters.<br>
<br>
The warning mechanism is only supported for gcc 10+.<br>
<br></blockquote><div><br></div><div>Interesting. My failing example uses gcc 10.3.0, the one that works uses 10.3.1 . Maybe there was a bug fix.</div></div></div>