Hi,
I'm reorganizing the OS and C library bindings in libstd (and moving
them to libcore). These are presently a highly-duplicated hodge-podge of
declarations scattered between modules that were placed in separate
per-platform files largely due to an old restriction in how we did
conditional compilation. So it needs cleanup, and I've got quite a bit
sketched on what to put in that cleanup already.
I'm less sure on the external interface and module structure to adopt.
I'm starting with the "lower level", which is the native libc part
itself, before moving up to the Rust-level "os" module on top.
The contents of a libc varies by platform. There are two conflicting
tensions in the matter:
- The definitions in a libc are typically present in "Compatibility
blocks" based on particular standards[1] (c89, c99, posix88,
posix08..) Sometimes when writing client code the presence of such
a compatibility block is a nice requirement to rest your code on.
- More-casual users often don't really care which compatibility block
some functionality comes from. You don't usually care that you get
SEEK_SET from c89 but O_RDWR from posix88. People tend to just
cargo-cult the #include lines until their code compiles.
So what I'm tentatively doing is putting *everything* you might want to
access from libc in core::libc, with a bunch of submodules for the
individual specs. Then importing and re-exporting all the symbols found
in the submodules at the core::libc::* level. So if you want to refer to
just "libc::creat" you can do so, but if you are being fussy you can do
"import libc::posix88;" and then use "posix88::creat" when you want it.
So, questions:
- Is this structure roughly ok? Useful? Silly?
- Should I put windows-specific parts of msvcrt in there as well?
- Is it wrong to try to "gather up" the bits found in common between
the ANSI C standard library[2] and the POSIX C standard library[3]?
- Is it wrong to call this library 'core::libc', is something else
better?
-Graydon
[1] http://upload.wikimedia.org/wikipedia/commons/4/46/SUS_History.svg
[2] http://en.wikipedia.org/wiki/C_Run-Time_Library#Header_files
[3] http://en.wikipedia.org/wiki/C_POSIX_library
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
