https://github.com/rust-lang/rust http://git.dreamy.place/mirrors/rust/atom?h=1.2.0 2015-07-29T17:49:13+00:00 2015-07-29T17:49:13+00:00 Alex Crichton alex@alexcrichton.com 2015-07-29T04:13:02+00:00 urn:sha1:e6b2f0cbaf4463f18936621b6e9fb44ecfb9f35f The API we're calling requires us to pass an absolute point in time as an argument (`pthread_cond_timedwait`) so we call `gettimeofday` ahead of time to then add the specified duration to. Unfortuantely the current "add the duration" logic forgot to take into account the current time's sub-second precision (e.g. the `tv_usec` field was ignored), causing sub-second duration waits to return spuriously. 2015-07-29T17:47:42+00:00 Lee Jeffery leejeffery@gmail.com 2015-07-16T13:36:05+00:00 urn:sha1:4fcb19dda999f8e1f97b98e170e87e47425e7dae 2015-06-22T04:55:42+00:00 Geoffrey Thomas geofft@ldpreload.com 2015-06-11T20:23:57+00:00 urn:sha1:a8dbb92b471cae1d3f8225857f5553311dd8aeb3 signal(), sigemptyset(), and sigaddset() are only available as inline functions until Android API 21. liblibc already handles signal() appropriately, so drop it from c.rs; translate sigemptyset() and sigaddset() (which is only used in a test) by hand from the C inlines. We probably want to revert this commit when we bump Android API level. 2015-06-22T04:55:42+00:00 Geoffrey Thomas geofft@ldpreload.com 2015-05-24T02:25:49+00:00 urn:sha1:cae005162d1d7aea6cffdc299fedf0d2bb2a4b28 Make sure that child processes don't get affected by libstd's desire to ignore SIGPIPE, nor a third-party library's signal mask (which is needed to use either a signal-handling thread correctly or to use signalfd / kqueue correctly). 2015-06-22T04:55:42+00:00 Geoffrey Thomas geofft@ldpreload.com 2015-05-23T22:07:52+00:00 urn:sha1:56d904c4bb4a10e6da3f03d11279e9a3f3d20d8b Both c.rs and stack_overflow.rs had bindings of libc's signal-handling routines. It looks like the split dated from #16388, when (what is now) c.rs was in libnative but not libgreen. Nobody is currently using the c.rs bindings, but they're a bit more accurate in some places. Move everything to c.rs (since I'll need signal handling in process.rs, and we should avoid duplication), clean up the bindings, and manually double-check everything against the relevant system headers (fixing a few things in the process). 2015-06-22T04:55:42+00:00 Geoffrey Thomas geofft@ldpreload.com 2015-05-22T21:30:06+00:00 urn:sha1:e13642163ab258c58295bcb1f2eaa27266724f73 It looks like a lot of this dated to previous incarnations of the io module, etc., and went unused in the reworking leading up to 1.0. Remove everything we're not actively using (except for signal handling, which will be reworked in the next commit). 2015-06-20T03:34:37+00:00 Geoffrey Thomas geofft@ldpreload.com 2015-06-20T01:11:10+00:00 urn:sha1:058a0f0b0bb1c39d620f7ce1d81150141c6a6341 The execv family of functions do not modify their arguments, so they do not need mutable pointers. The C prototypes take a constant array of mutable C-strings, but that's a legacy quirk from before C had const (since C string literals have type `char *`). The Rust prototypes had `*mut` in the wrong place, anyway: to match the C prototypes, it should have been `*const *mut c_char`. But it is safe to pass constant strings (like string literals) to these functions. getopt is a special case, since GNU getopt modifies its arguments despite the `const` claim in the prototype. It is apparently only well-defined to call getopt on the actual argc and argv parameters passed to main, anyway. Change it to take `*mut *mut c_char` for an attempt at safety, but probably nobody should be using it from Rust, since there's no great way to get at the parameters as passed to main. Also fix the one caller of execvp in libstd, which now no longer needs an unsafe cast. Fixes #16290. 2015-06-18T23:14:50+00:00 Alex Crichton alex@alexcrichton.com 2015-06-18T23:14:50+00:00 urn:sha1:45f830b18c58fa5a3020d8a92144b05b551b9074 These were just left out by mistake! 2015-06-18T17:51:31+00:00 Alex Crichton alex@alexcrichton.com 2015-06-12T17:49:39+00:00 urn:sha1:ec333380e03eb1fb94c4938db888d5bed40b8fd6 2015-06-17T16:07:17+00:00 Alex Crichton alex@alexcrichton.com 2015-06-11T02:33:04+00:00 urn:sha1:b4a2823cd6c6f1a560469587f902f3a1f49d3c79