• solidstate1991 (10/10) Sep 07 2018 While for the most part it still works very well, however when
• Laurent =?UTF-8?B?VHLDqWd1aWVy?= (8/18) Sep 09 2018 I thought the same after having to use Windows-specific functions
• Jonathan M Davis (22/41) Sep 10 2018 Historically, most of the Win32 API has been missing from druntime, and ...
• Laurent =?UTF-8?B?VHLDqWd1aWVy?= (17/41) Sep 10 2018 I don't remember what API I was thinking about using and didn't
• Jonathan M Davis (23/33) Sep 10 2018 If you need a specific C function, it's trivial to create the binding in
• Steven Schveighoffer (9/12) Sep 10 2018 It will be updated when you update it ;)
• Laeeth Isharc (5/15) Sep 10 2018 dpp has worked for most C headers I tried and if not then file a

solidstate1991 <laszloszeremi outlook.com> writes:

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.

Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

Steven Schveighoffer <schveiguy gmail.com> writes:

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

Laeeth Isharc <Laeeth laeeth.com> writes:

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.