<div dir="ltr"><div dir="ltr">On Tue, Jun 25, 2019 at 4:32 PM Zachary Turner <<a href="mailto:zturner@roblox.com">zturner@roblox.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The main concern I have is that Windows is so different from<br>
everything else that there is a high likelihood of decisions being<br>
baked in early on that make things very difficult for people to come<br>
along later and contribute a Windows implementation.  This happened<br>
with sanitizers for example (lack of support for weak functions on<br>
Windows), LLDB (posix api calls scattered throughout the codebase),<br>
and I worry with libc it will be even more difficult to correctly<br>
design the abstraction because we have to deal with executable file<br>
format, syscalls, operating system loaders, and various linkage<br>
models.<br>
<br>
The most immediate thing I think we will run into is that you<br>
mentioned wanting this to take shape as something that sits in between<br>
system libc and application.  Given that Windows' libc and other<br>
versions of libc are so different, I expect this to lead to some<br>
interesting problems.<br>
<br>
Can you elaborate more on how you envision this working with llvm libc<br>
in between application and system libc?<br></blockquote><div><br></div><div>A typical application uses a large number of pieces from a libc. But, it is not practical to have everything implemented and ready in a new libc from day one. So for that phase, when the new libc is still being built, we want the unimplemented parts of the new libc to essentially redirect to the system libc. This brings two benefits:</div><div><br></div><div>1. We can build the new libc in a gradual manner.</div><div>2. Applications stay operational while gaining the benefits of the new implementations.</div><div><br></div><div>Do you foresee any problems with this approach on Windows?</div></div></div>