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

[Kim Barrett]

> On Jun 30, 2022, at 1:21 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Thomas,
> 
> On 30/06/2022 2:57 pm, Thomas Stüfe wrote:
>> Hi,
>> several functions in the os:: name scope are deliberately named like the official counterparts they replace:
>> os::malloc, os::free, os::strdup, os::realloc, os::recv, os::send, os::connect, os::signal...
>> There may be more. Some of them argument-match their counterparts (e.g. os::free), while others don't.
>> Since the os:: variants can be called inside the os:: namespace with omitting the leading os::, name confusions are possible. "free(p)" means something different in global scope or inside an os:: function.
>> This can lead to problems that are difficult to find, e.g., mismatched (os::)malloc->(os::)free with the potential to corrupt the C-heap:
>> […] So I wonder if we should do that. Rename os::<function> to something like os::<prefix><function>. And what the prefix or suffix would be.
> 
> It annoys me that we have to do such things. It would have made more sense for the standard C library routines to have a prefix that marked them as reserved identifiers rather than polluting the global namespace the way they did. But no one thinks of these things initially and by the time it is standardised it is too late to make such changes. :(
> 
> I'm not sure this is a problem we have to address, but if we choose to then I think we should try to make a general improvement to the way os is used.
> 
> Maybe, as I think has been suggested before, we can move these out of the os class as they are not really about the os but the C library, and then any renaming that includes a prefix may not look so bad?
> 
> Maybe lib::C_free(), lib::C_malloc() etc?

A reminder that JDK-8214976 allows us to "poison" a function, other than in
explicitly marked places. When I introduced that feature I only marked a small
number of functions that were "easy". There are many other functions that seem
like good candidates, but had more fannout than I wanted in that change. For
example, we could mark ::malloc, ::calloc, ::free, &etc as normally forbidden.