Should we rename os:: functions that are named like standard C- or Posix-functions?

Thomas Stüfe thomas.stuefe at gmail.com
Mon Jul 4 13:36:06 UTC 2022


On Mon, Jul 4, 2022 at 12:46 PM Kim Barrett <kim.barrett at oracle.com> wrote:

> > On Jul 4, 2022, at 3:18 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> > On Sun, Jul 3, 2022 at 10:59 PM Kim Barrett <kim.barrett at oracle.com>
> wrote:
> > > On Jul 3, 2022, at 4:47 AM, Thomas Stüfe <thomas.stuefe at gmail.com>
> wrote:
> > >
> > > I am preparing a patch to forbid C-heap allocation functions in
> hotspot as you proposed (https://github.com/openjdk/jdk/pull/9356).
> > >
> > > 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.
> >
> > In which build variants?  All?  Or only fastdebug?  If the latter, this
> might be another case of
> > _FORTIFY_SOURCE rewriting the call first, dodging the warning.  This is
> mentioned in the
> > comment describing the gcc implementation of FORBID_C_FUNCTION.
> >
> >
> > 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.
>
> It works (fails with expected warning) for me.  gcc 11.2, in case that
> matters.
>
> The warning mechanism is only supported for gcc 10+.
>
>
Interesting. My failing example uses gcc 10.3.0, the one that works uses
10.3.1 . Maybe there was a bug fix.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220704/e311d9f6/attachment-0001.htm>


More information about the hotspot-dev mailing list