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

[David Holmes]

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:
> 
> https://bugs.openjdk.org/browse/JDK-8289477 
> <https://bugs.openjdk.org/browse/JDK-8289477>
> 
> And I remember having similar problems in the past. They don't happen 
> often, but if they do, they take some investigation time since they are 
> rarely obvious.
> 
> I discussed the above problem with the muslc devs 
> https://www.openwall.com/lists/musl/2022/06/29/3 
> <https://www.openwall.com/lists/musl/2022/06/29/3>, and their position 
> is understandable that we should not use names of standard functions.
> 
> 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?

Cheers,
David
-----

> Thanks, Thomas
>