This is mostly out of curiosity, but also relevant for any future contributions to Phobos:

1. AFAIK, the full interface for the C standard library is in druntime,
specifically the core.stdc package, with OS-dependent stuff in core.sys.
  Yet, there still exists an std.c package in Phobos that contains more
or less the same things, and which is used extensively throughout the
rest of the library.  Is this intentional, or am I just seeing the
relics of pre-druntime Phobos?

2. Phobos uses functions from the C standard library in favour of native D implementations in several places.  (In light of recent discussions, std.stdio.File comes quickly to mind.)  Is this just a way of getting things up and running quickly, with the intention of D-ifying things later, or is it considered a permanent solution?

-Lars

On Apr 7, 2010, at 2:35 AM, Lars Tandle Kyllingstad wrote:

> This is mostly out of curiosity, but also relevant for any future contributions to Phobos:
> 
> 1. AFAIK, the full interface for the C standard library is in druntime, specifically the core.stdc package, with OS-dependent stuff in core.sys.  Yet, there still exists an std.c package in Phobos that contains more or less the same things, and which is used extensively throughout the rest of the library.  Is this intentional, or am I just seeing the relics of pre-druntime Phobos?

A bit of both.  When std.c was moved it was easier to turn those into forwarding modules.  They remain mostly because some contain nonstandard declarations and I haven't spent much time working on core.sys, though perhaps the proper thing in the case of what's left in std.c is just to declare it privately inside the Phobos module that needs the routine.

> 2. Phobos uses functions from the C standard library in favour of native D implementations in several places.  (In light of recent discussions, std.stdio.File comes quickly to mind.)  Is this just a way of getting things up and running quickly, with the intention of D-ifying things later, or is it considered a permanent solution?

core.stdc is present as much for users who want to port C code to D as anything else.  But I do see use of standard C routines as an indicator of where gaps are in Phobos.  It's really there "just in case."

On 04/07/2010 10:27 AM, Sean Kelly wrote:
> On Apr 7, 2010, at 2:35 AM, Lars Tandle Kyllingstad wrote:
>
>> This is mostly out of curiosity, but also relevant for any future contributions to Phobos:
>>
>> 1. AFAIK, the full interface for the C standard library is in druntime, specifically the core.stdc package, with OS-dependent stuff in core.sys.  Yet, there still exists an std.c package in Phobos that contains more or less the same things, and which is used extensively throughout the rest of the library.  Is this intentional, or am I just seeing the relics of pre-druntime Phobos?
>
> A bit of both.  When std.c was moved it was easier to turn those into forwarding modules.  They remain mostly because some contain nonstandard declarations and I haven't spent much time working on core.sys, though perhaps the proper thing in the case of what's left in std.c is just to declare it privately inside the Phobos module that needs the routine.
>
>> 2. Phobos uses functions from the C standard library in favour of native D implementations in several places.  (In light of recent discussions, std.stdio.File comes quickly to mind.)  Is this just a way of getting things up and running quickly, with the intention of D-ifying things later, or is it considered a permanent solution?
>
> core.stdc is present as much for users who want to port C code to D as anything else.  But I do see use of standard C routines as an indicator of where gaps are in Phobos.  It's really there "just in case."

In principle there's nothing wrong with using C functions, but the main problem is that many of them have problems, and others are unpleasant to use with D. Examples:

- atoi() is very wrong because not only it doesn't handle errors, it prevents the caller from diagnosing them.

- Many (strtoul, printf, etc. etc.) use pointers and char*-based interfaces that are unpleasant and unsafe with D.

- Some (e.g gets, sprintf) are extremely dangerous by design and can't be made safe.

What remains is a small core of functions such as stat(), which we can use no problem.


Andrei