misc: Use external freestanding headers implementation

[mintsuki]

No description provided.

[Geertiebear]

What does this PR fix?

[mintsuki]

It is not a fix for anything. It makes mlibc rely on an external, more complete implementation of the freestanding C headers instead of its internal ones which were rather incomplete.

[Geertiebear]

How incomplete are they?

[mintsuki]

Refer to limits.h for example. In general they are incomplete enough that relying on an external implementation instead of NIH'ing them makes some sense, but it is subject to personal preference.

[ikbenlike]

as I mentioned before on discord, I approve of this idea but I do not have the means to verify the correctness of this particular implementation. I would say that the rationale is similar as with the linux-headers situation, in that there is no need to maintain a set of headers like this ourselves

[Dennisbonke]

Not against this. However, this would break Managarm if I'm not mistaken, can you prepare a PR for bootstrap-managarm too?

[mintsuki]

Not against this. However, this would break Managarm if I'm not mistaken, can you prepare a PR for bootstrap-managarm too?

@Dennisbonke see bootstrap-managarm#232

[Geertiebear]

Refer to limits.h for example. In general they are incomplete enough that relying on an external implementation instead of NIH'ing them makes some sense, but it is subject to personal preference.

I'd prefer then that we just embed the external headers into mlibc then. Are they really so complex and change so often that we should rely on an external repository? Seems better to me to just add the missing parts to mlibc.

[mintsuki]

You make a compelling point, honestly. You can freely copy my freestanding headers licensed under the 0BSD license into mlibc if you want.

The idea of this PR is more about making it work similarily to linux-headers and ensuring that changes and new addition to the freestanding headers are "automatically" reflected.

The freestanding headers are usually modified or changed to support new language standards and features, but you're right in that this is not something that happens all the time and it can be easily backported to the mlibc tree itself.

[Geertiebear]

Sorry it's taken me so long to get back to this. I agree that it would be useful to have the freestanding headers automatically updated. Currently mlibc doesn't have a unified way of dealing with external packages (tracked in issue #601). I propose that until we have that issue in order this PR instead copies the new freestanding headers into the current tree, and we make a new issue to make sure we don't forget that we need to keep it in sync. Then once we figured out a good way to keep third party code in sync we can change it over to the external repo.

Reason I'm saying this is because as it stands this PR would add some annoyance to the developer workflow, which I'd rather avoid for now.