core.sys/core.stdc vs. std.c?

[Sean Kelly]

The windows bit was more an issue of that we needed the code somewhere and it was windows-specific, so sys.windows seemed a passable choice. The alternative would be core.internal, though I'm trying to avoid the need for that approach. If you have suggestions for how to handle this, please let me know :-)

Sent from my iPhone

On Jun 12, 2011, at 8:37 AM, David Nadlinger <see at klickverbot.at> wrote:

> On 6/12/11 5:06 PM, Andrei Alexandrescu wrote:
>> On 6/12/11 1:38 AM, David Nadlinger wrote:
>>> core.stdc is the place for C standard library modules, core.sys.* are
>>> where the C operating system header translations reside – this is our
>>> current policy, right? If so (I can't actually remember any formal
>>> decision or discussion), is there a reason we still have so much code in
>>> std.c?
>>> 
>>> David
>> 
>> The reason is a smart GSoC student didn't yet come and deprecate them :o).
> 
> Smart? Can't possibly be me… ;)
> 
> On a closer look, I discovered that contrary to core.sys.posix and core.sys.osx, which only have C header translations, core.sys.windows.* also contains support code like backtrace.d, thradaux.d, etc.
> 
> Is the »official« package structure actually documented anywhere?
> 
> David