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

[Thomas Stüfe]

On Mon, Jul 4, 2022 at 10:04 AM Kim Barrett <kim.barrett at oracle.com> wrote:

> > On Jul 4, 2022, at 3:55 AM, 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: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.
>
> One option is to put it in a separate file and use gcc's `-include` option
> to ensure it is included
> everywhere.  But (2) is still an issue, so other refactoring of
> globalDefinitions.hpp would also
> be needed.  (Not that such refactoring would be a bad thing, IMO.)
>
>
I also realized that we almost always need macros.hpp for platform
dependent switch macros. It is probably okay as it is. Maybe we could add a
rule to the style guide saying that every cpp file should include
globalDefinitions.hpp, similar to windows.h on Windows.

But the mechanism is already very good. I can live with it as it is now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20220704/14471eb1/attachment.htm>