<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 30, 2022 at 7:21 AM David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Thomas,<br>
<br>
On 30/06/2022 2:57 pm, Thomas Stüfe wrote:<br>
> Hi,<br>
> <br>
> several functions in the os:: name scope are deliberately named like the <br>
> official counterparts they replace:<br>
> <br>
> os::malloc, os::free, os::strdup, os::realloc, os::recv, os::send, <br>
> os::connect, os::signal...<br>
> <br>
> There may be more. Some of them argument-match their counterparts (e.g. <br>
> os::free), while others don't.<br>
> <br>
> Since the os:: variants can be called inside the os:: namespace with <br>
> omitting the leading os::, name confusions are possible. "free(p)" means <br>
> something different in global scope or inside an os:: function.<br>
> <br>
> This can lead to problems that are difficult to find, e.g., mismatched <br>
> (os::)malloc->(os::)free with the potential to corrupt the C-heap:<br>
> <br>
> <a href="https://bugs.openjdk.org/browse/JDK-8289477" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8289477</a> <br>
> <<a href="https://bugs.openjdk.org/browse/JDK-8289477" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8289477</a>><br>
> <br>
> And I remember having similar problems in the past. They don't happen <br>
> often, but if they do, they take some investigation time since they are <br>
> rarely obvious.<br>
> <br>
> I discussed the above problem with the muslc devs <br>
> <a href="https://www.openwall.com/lists/musl/2022/06/29/3" rel="noreferrer" target="_blank">https://www.openwall.com/lists/musl/2022/06/29/3</a> <br>
> <<a href="https://www.openwall.com/lists/musl/2022/06/29/3" rel="noreferrer" target="_blank">https://www.openwall.com/lists/musl/2022/06/29/3</a>>, and their position <br>
> is understandable that we should not use names of standard functions.<br>
> <br>
> So I wonder if we should do that. Rename os::<function> to something <br>
> like os::<prefix><function>. And what the prefix or suffix would be.<br>
<br>
It annoys me that we have to do such things. It would have made more <br>
sense for the standard C library routines to have a prefix that marked <br>
them as reserved identifiers rather than polluting the global namespace <br>
the way they did. But no one thinks of these things initially and by the <br>
time it is standardised it is too late to make such changes. :(<br>
<br></blockquote><div><br></div><div>I am not sure that would have helped. The original VM authors seemed to deliberately duplicate the official names. Had the inventors of the C-standard used a common prefix, we may have copied that too. But that's ancient history, I don't know who introduced os:: and what their thoughts were.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm not sure this is a problem we have to address, but if we choose to <br>
then I think we should try to make a general improvement to the way os <br>
is used.<br>
<br>
Maybe, as I think has been suggested before, we can move these out of <br>
the os class as they are not really about the os but the C library, and <br>
then any renaming that includes a prefix may not look so bad?<br>
<br>
Maybe lib::C_free(), lib::C_malloc() etc?<br>
<br></blockquote><div><br></div><div>I'd be fine with that. Other possibilities for such a namespace could be "system" or permutations thereof, e.g. "sys::c_free()" etc. Avoids discussions about what is a C-standard function, what is a Posix function, etc.</div><div><br></div><div>Cheers, Thomas</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Cheers,<br>
David<br>
-----<br>
<br>
> Thanks, Thomas<br>
> <br>
</blockquote></div></div>