Am Sun, 26 Feb 2012 18:00:49 -0300 schrieb Leandro Lucarella <l...@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.
