Should we rename os:: functions that are named like standard C- or Posix-functions?
Kim Barrett
kim.barrett at oracle.com
Mon Jul 4 07:55:46 UTC 2022
> 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.
Strange. Maybe there’s some other similar rewrite going on? I’ll try poking at this.
> 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.
I thought about putting the forbiddings in a different file, but ultimately decided not.
1. globalDefinitions.hpp ends up being included nearly everywhere anyway, almost certainly in places
where these functions would be used. It’s currently such a dumping ground for miscellaneous and
often unrelated things that it ends up being hard to avoid.
2. globalDefinitions.hpp is where we do whatever conditionalization is needed to #include a lot of
the relevant “system” and C library headers and perform some additional massaging of them.
These poisonings may involve parameter and return types from those headers.
More information about the hotspot-dev
mailing list