Re: Will the core.stdc module be updated for newer versions of C?

2018-09-10 Thread Laeeth Isharc via Digitalmars-d
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.




Re: Will the core.stdc module be updated for newer versions of C?

2018-09-10 Thread Laurent Tréguier via Digitalmars-d
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.


Re: Will the core.stdc module be updated for newer versions of C?

2018-09-10 Thread Steven Schveighoffer via Digitalmars-d

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 
 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


Re: Will the core.stdc module be updated for newer versions of C?

2018-09-10 Thread Jonathan M Davis via Digitalmars-d
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






Re: Will the core.stdc module be updated for newer versions of C?

2018-09-10 Thread Jonathan M Davis via Digitalmars-d
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





Re: Will the core.stdc module be updated for newer versions of C?

2018-09-09 Thread Laurent Tréguier via Digitalmars-d
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.


Will the core.stdc module be updated for newer versions of C?

2018-09-07 Thread solidstate1991 via Digitalmars-d
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.