Restructuring druntime

Johannes Pfau nospam at example.com
Sun Feb 26 13:34:46 PST 2012


Am Sun, 26 Feb 2012 18:00:49 -0300
schrieb Leandro Lucarella <luca at llucax.com.ar>:

> Kagamin, el 26 de febrero a las 19:30 me escribiste:
> > On Sunday, 26 February 2012 at 13:06:58 UTC, Johannes Pfau wrote:
> > >still have to make sure core.* works.
> > 
> > That's an issue. Given the c libraries incompatibilities, what
> > functionality the core.stdc should provide? What to do with
> > functions like backtrace?
> 
> Backtrace is not stdc :)
> 
> I'm sorry to interject when I'm not very involved, but libraries
> implementing the C standard library should not be too different from
> each other. Maybe some miss some features, but the things they have,
> should be pretty much the same.

I mostly agree. The API of the C libraries is the same, what's
different is ABI: The C/Posix standards don't define layouts for some
structs, for example the 'stat' struct is different between most C
libraries. That's the reason we need different bindings for different C
libraries.
> 
> I think core.stdc should publicly import the local compiler's stdc.
> Any incompatibilities among different libraries should be handled by
> the users of core.stdc, not core.stdc itself, which is supposed to be
> just a thin layer to get what the current C environment have. People
> should be using std stuff, not core.stdc, most of the time, specially
> if they intend to write portable code.
> 
I agree. The question is how that 'publicly import' should actually
work. Using real 'public import' statements with static if/version
blocks adds some additional clutter. Placing bindings for different C
libraries in different directories and just compiling in the correct
folder seems to be the easiest solution.



More information about the D.gnu mailing list