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