core: Clean up comments and exports

This commit is contained in:
Brian Anderson 2012-03-10 00:04:09 -08:00
parent 93a082149a
commit a0f0a704b0
6 changed files with 135 additions and 38 deletions

View File

@ -1,36 +1,38 @@
//
// We consider the following specs reasonably normative with respect
// to interoperating with the C standard library (libc/msvcrt):
//
// - ISO 9899:1990 ('C95', 'ANSI C', 'Standard C'), NA1, 1995.
// - ISO 9899:1999 ('C99' or 'C9x').
// - ISO 9945:1988 / IEEE 1003.1-1988 ('POSIX.1').
// - ISO 9945:2001 / IEEE 1003.1-2001 ('POSIX:2001', 'SUSv3').
// - ISO 9945:2008 / IEEE 1003.1-2008 ('POSIX:2008', 'SUSv4').
//
// Despite having several names each, these are *reasonably* coherent
// point-in-time, list-of-definition sorts of specs. You can get each under a
// variety of names but will wind up with the same definition in each case.
//
// Our interface to these libraries is complicated by the non-universality of
// conformance to any of them. About the only thing universally supported is
// the first (C95), beyond that definitions quickly become absent on various
// platforms.
//
// We therefore wind up dividing our module-space up (mostly for the sake of
// sanity while editing, filling-in-details and eliminating duplication) into
// definitions common-to-all (held in modules named c95, c99, posix88, posix01
// and posix08) and definitions that appear only on *some* platforms (named
// 'extra'). This would be things like significant OSX foundation kit, or
// win32 library kernel32.dll, or various fancy glibc, linux or BSD
// extensions.
//
// In addition to the per-platform 'extra' modules, we define a module of
// "common BSD" libc routines that never quite made it into POSIX but show up
// in multiple derived systems. This is the 4.4BSD r2 / 1995 release, the
// final one from Berkeley after the lawsuits died down and the CSRG
// dissolved.
//
#[doc = "
Bindings for libc.
We consider the following specs reasonably normative with respect
to interoperating with the C standard library (libc/msvcrt):
* ISO 9899:1990 ('C95', 'ANSI C', 'Standard C'), NA1, 1995.
* ISO 9899:1999 ('C99' or 'C9x').
* ISO 9945:1988 / IEEE 1003.1-1988 ('POSIX.1').
* ISO 9945:2001 / IEEE 1003.1-2001 ('POSIX:2001', 'SUSv3').
* ISO 9945:2008 / IEEE 1003.1-2008 ('POSIX:2008', 'SUSv4').
Despite having several names each, these are *reasonably* coherent
point-in-time, list-of-definition sorts of specs. You can get each under a
variety of names but will wind up with the same definition in each case.
Our interface to these libraries is complicated by the non-universality of
conformance to any of them. About the only thing universally supported is
the first (C95), beyond that definitions quickly become absent on various
platforms.
We therefore wind up dividing our module-space up (mostly for the sake of
sanity while editing, filling-in-details and eliminating duplication) into
definitions common-to-all (held in modules named c95, c99, posix88, posix01
and posix08) and definitions that appear only on *some* platforms (named
'extra'). This would be things like significant OSX foundation kit, or
win32 library kernel32.dll, or various fancy glibc, linux or BSD
extensions.
In addition to the per-platform 'extra' modules, we define a module of
'common BSD' libc routines that never quite made it into POSIX but show up
in multiple derived systems. This is the 4.4BSD r2 / 1995 release, the
final one from Berkeley after the lawsuits died down and the CSRG
dissolved.
"];
// Initial glob-exports mean that all the contents of all the modules
// wind up exported, if you're interested in writing platform-specific code.

View File

@ -1,4 +1,13 @@
#[doc = "Unsafe pointer utility functions"]
#[doc = "Unsafe pointer utility functions"];
export addr_of;
export mut_addr_of;
export offset;
export mut_offset;
export null;
export memcpy;
export memmove;
#[abi = "rust-intrinsic"]
native mod rusti {

View File

@ -1,4 +1,13 @@
#[doc = "Misc low level stuff"]
#[doc = "Misc low level stuff"];
export type_desc;
export get_type_desc;
export last_os_error;
export size_of;
export align_of;
export refcount;
export log_str;
export set_exit_status;
enum type_desc = {
first_param: **ctypes::c_int,

View File

@ -2,6 +2,77 @@ import option::{some, none};
import uint::next_power_of_two;
import ptr::addr_of;
export init_op;
export is_empty;
export is_not_empty;
export same_length;
export reserve;
export len;
export init_fn;
export init_elt;
export to_mut;
export from_mut;
export head;
export tail;
export tail_n;
export init;
export last;
export last_opt;
export slice;
export split;
export splitn;
export rsplit;
export rsplitn;
export shift;
export pop;
export push;
export grow;
export grow_fn;
export grow_set;
export map;
export map2;
export filter_map;
export filter;
export concat;
export connect;
export foldl;
export foldr;
export any;
export any2;
export all;
export all2;
export contains;
export count;
export find;
export find_from;
export rfind;
export rfind_from;
export position_elt;
export position;
export position_from;
export position_elt;
export rposition;
export rposition_from;
export unzip;
export zip;
export swap;
export reverse;
export reversed;
export enum_chars;
export enum_uints;
export iter;
export iter2;
export iteri;
export riter;
export riteri;
export permute;
export windowed;
export as_buf;
export as_mut_buf;
export vec_len;
export unsafe;
export u8;
#[abi = "rust-intrinsic"]
native mod rusti {
fn vec_len<T>(&&v: [const T]) -> ctypes::size_t;
@ -808,6 +879,7 @@ impl vec_len<T> for [T] {
}
mod unsafe {
// FIXME: This should have crate visibility
type vec_repr = {mutable fill: uint, mutable alloc: uint, data: u8};
#[doc = "

View File

@ -0,0 +1,3 @@
native mod rustrt {
fn last_os_error() -> str;
}

View File

@ -1,10 +1,12 @@
use std;
import sys;
// xfail-fast
// aux-build:native_lib.rs
// The purpose of this test is to check that we can
// successfully (and safely) invoke external, cdecl
// functions from outside the crate.
use native_lib;
fn main() {
let foo = sys::rustrt::last_os_error();
let foo = native_lib::rustrt::last_os_error();
}