While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).

While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.

On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991 wrote:
> While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).
>
> While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.

I thought the same after having to use Windows-specific functions from `core.sys.windows`, some (presumably newer) functions are missing from the definitions.
At that time I thought about trying to get my hands dirty on this, but I don't know how much time it would take to do that though.

On Friday, September 7, 2018 7:12:30 PM MDT solidstate1991 via Digitalmars-d wrote:
> While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).
>
> While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.

If you need a specific C function, it's trivial to create the binding in your own code. So, just because a binding is missing from druntime doesn't mean that you have to write your own solution rather than using the C solution. druntime contains the stdc and OS bindings for convenience and because some of them are necessary for druntime, Phobos, and dmd, but a binding doesn't have to actually be there for you to be able to use a C stdc function. It's just more convenient that way.

In any case, if you find that a particular stdc function has no bindings in druntime, feel free to create a PR. The same goes for OS functions (though those are more of a mess - especially on Windows). While occasionally, someone will go to a lot of effort to improve or update some portion of the bindings, for the most part, they only get changed when someone figures out that they need to be updated, or there's a particular binding that they want that isn't there. Those bindings aren't usually very actively maintained in the sense that someone is regularly taking the time to ensure that every binding that should be there is there or that they're all up-to-date. Most of the symbols involved change very rarely, so they don't need to be updated often, but because no one is really focusing on them, pretty much the only way that a new symbol is gets added is because someone wants to use it, figures out that it's missing, and creates a PR for it.

- Jonathan M Davis

On Sunday, September 9, 2018 11:37:54 AM MDT Laurent Tréguier via Digitalmars-d wrote:
> On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991
>
> wrote:
> > While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).
> >
> > While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.
>
> I thought the same after having to use Windows-specific functions
> from `core.sys.windows`, some (presumably newer) functions are
> missing from the definitions.
> At that time I thought about trying to get my hands dirty on
> this, but I don't know how much time it would take to do that
> though.

Historically, most of the Win32 API has been missing from druntime, and many of the symbols were in the wrong place (they should really be in modules corresponding to the C headers that the symbols come from, but many of them were just put in core.sys.windows.windows as if everything were in windows.h). Most folks doing serious stuff with the Win32 API used to use an external project that had a much more thorough version of the bindings (though I can't find it at the moment, looking around for D projects with Win and API in the name, so I don't know what happened to it). However, looking over what's in druntime for Windows now, it looks like Vladimir added a ton of bindings back in 2015 (probably from that external project). So, it would appear that the situation for the Windows bindings in druntime is _way_ better than it used to be.

Regardless, if you find that a particular binding is missing, feel free to create a PR for it. Usually, such bindings only get added when someone wants to use a particular C function and then discovers that the binding is missing, so they create a PR to add it. It's not like we have a system for discovering all of the bindings that are supposed to be there, and while occasionally, someone will make an effort to make the bindings more comprehensive, it's not something that's regularly worked on.

- Jonathan M Davis

On 9/7/18 6:12 PM, solidstate1991 wrote:
> While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).

It will be updated when you update it ;)

There is just so much in the stdc libraries that it's difficult to achieve 100% coverage. The intention is for any time you have a #include <someFilePath.h> for some C standard header, you can do import core.stdc.someFilePath in D. If there are missing functions, and they aren't OS specific, please file a bug report, and if you're up to it, add the function in a PR.

-Steve

On Monday, 10 September 2018 at 07:43:52 UTC, Jonathan M Davis wrote:
> Historically, most of the Win32 API has been missing from druntime, and many of the symbols were in the wrong place (they should really be in modules corresponding to the C headers that the symbols come from, but many of them were just put in core.sys.windows.windows as if everything were in windows.h). Most folks doing serious stuff with the Win32 API used to use an external project that had a much more thorough version of the bindings (though I can't find it at the moment, looking around for D projects with Win and API in the name, so I don't know what happened to it). However, looking over what's in druntime for Windows now, it looks like Vladimir added a ton of bindings back in 2015 (probably from that external project). So, it would appear that the situation for the Windows bindings in druntime is _way_ better than it used to be.
>
> Regardless, if you find that a particular binding is missing, feel free to create a PR for it. Usually, such bindings only get added when someone wants to use a particular C function and then discovers that the binding is missing, so they create a PR to add it. It's not like we have a system for discovering all of the bindings that are supposed to be there, and while occasionally, someone will make an effort to make the bindings more comprehensive, it's not something that's regularly worked on.
>
> - Jonathan M Davis

I don't remember what API I was thinking about using and didn't find in druntime, but as far as I can recall I ended up using another API anyway.

I just pulled up a Bash for Windows prompt:

$ cd /mnt/b/Program\ Files/D/dmd2/src/druntime/src/core/sys/windows
$ ls *.d | wc -l
165
$ cd /mnt/c/Program\ Files\ \(x86\)/Windows\ Kits/10/Include
$ ls 10.0.17134.0/um/*.h | wc -l
1443

I think that perhaps I see know why the bindings aren't going get an overhaul and be up to date just like that...

I'll be sure to make a PR whenever I stumble upon missing ones I feel like using though.

On Saturday, 8 September 2018 at 01:12:30 UTC, solidstate1991 wrote:
> While for the most part it still works very well, however when porting Mago I found a few functions that are not present in C99 (most notably wcsncpy_s).
>
> While I can write my own functions to do the same (already done this with C++'s array since a few classes inherited from std::vector, hopefully I don't need to fiddle too much with it on the Debug engine to limit reliance on GC) I think it would be a good idea to do some updates on the runtime library in this regard, especially as it's a very easily available @nogc library too.

dpp has worked for most C headers I tried and if not then file a GitHub issue and we will fix it.  I think C++ will come step by step in time, though it's quite a lot of work.