about summary refs log tree commit diff
path: root/src/libstd/sys/unix
AgeCommit message (Collapse)AuthorLines
2020-07-27mv std libs to library/mark-11329/+0
2020-07-23Rollup merge of #74606 - cuviper:cloexec, r=sfacklerManish Goregaokar-195/+74
Remove Linux workarounds for missing CLOEXEC support Now that #74163 updated the minimum Linux kernel to 2.6.32, we can assume the availability of APIs that open file descriptors that are already set to close on exec, including the flags `O_CLOEXEC`, `SOCK_CLOEXEC`, and `F_DUPFD_CLOEXEC`. Closes #74519.
2020-07-23Rollup merge of #74587 - lzutao:consts, r=dtolnayManish Goregaokar-16/+17
Prefer constant over function Just that I prefer constants over functions that can be made const.
2020-07-23Rollup merge of #74141 - euclio:typos, r=steveklabnikManish Goregaokar-2/+2
libstd/libcore: fix various typos
2020-07-23Prefer constant over functionLzu Tao-16/+17
2020-07-22Move the pipe2 call behind a hard target `#[cfg]`Josh Stone-21/+29
2020-07-21Remove Linux workarounds for missing CLOEXEC supportJosh Stone-187/+58
Now that #74163 updated the minimum Linux kernel to 2.6.32, we can assume the availability of APIs that open file descriptors that are already set to close on exec, including the flags `O_CLOEXEC`, `SOCK_CLOEXEC`, and `F_DUPFD_CLOEXEC`.
2020-07-19Rollup merge of #74356 - lzutao:rm_combine, r=LukasKalbertodtManish Goregaokar-7/+3
Remove combine function Comparing two array directly helps generate better assert message. Resolve https://github.com/rust-lang/rust/pull/74271/files#r454538514
2020-07-16apply bootstrap cfgsMark Rousskov-2/+2
2020-07-15Rollup merge of #74291 - regexident:from-docs, r=GuillaumeGomezManish Goregaokar-0/+2
Added docs for `From<c_int>` for `ExitStatus` Partially addresses https://github.com/rust-lang/rust/issues/51430
2020-07-15Remove combine functionLzu Tao-7/+3
Comparing two array directly helps generate better assert message
2020-07-14Rollup merge of #74271 - lzutao:cmdbytes, r=LukasKalbertodtManish Goregaokar-14/+12
process_unix: prefer i32::*_be_bytes over manually shifting bytes This PR makes it more clear about the intend of the code.
2020-07-14Added docs for `From<c_int>` for `ExitStatus`Vincent Esche-0/+2
2020-07-12process_unix: prefer i32::*_be_bytes over manually shifting bytesLzu Tao-14/+12
2020-07-12adjust remaining targetsRalf Jung-1/+1
2020-07-12rename fast_thread_local -> thread_local_dtor; thread_local -> thread_local_keyRalf Jung-3/+6
2020-07-09libstd/libcore: fix various typosAndy Russell-2/+2
2020-07-07Auto merge of #74006 - euclio:sys-unix-static-mut, r=oli-obkbors-26/+33
libstd: remove some mutable statics in sys::unix My understanding is that this achieves the same behavior and performance with safe code.
2020-07-06libstd: remove some mutable statics in sys::unixAndy Russell-26/+33
2020-07-02Fix linksGuillaume Gomez-1/+1
2020-06-28Rename the lint to clashing_extern_declarations.jumbatm-2/+2
Also, run RustFmt on the clashing_extern_fn test case and update stderrs.
2020-06-23Remove unused crate imports in 2018 edition cratesyuqio-3/+0
2020-06-21Auto merge of #70946 - jumbatm:clashing-extern-decl, r=nagisabors-0/+2
Add a lint to catch clashing `extern` fn declarations. Closes #69390. Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake. This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect. r? @eddyb
2020-06-20Rollup merge of #73171 - tblah:riscv-qemu-test, r=pietroalbiniRalf Jung-0/+1
RISC-V Emulated Testing Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image. Test using ``` ./src/ci/docker/run.sh riscv64gc-linux ``` cc: @msizanoen1
2020-06-20Add ClashingExternDecl lint.jumbatm-0/+2
This lint checks that all declarations for extern fns of the same name are declared with the same types.
2020-06-18Document format correctionqy3u-2/+4
2020-06-10Migrate to numeric associated constsLzu Tao-20/+12
2020-06-09Mark tests whcih don't work under riscv emulationTom Eccles-0/+1
2020-05-25Auto merge of #72472 - LeSeulArtichaut:sync-command, r=dtolnaybors-2/+4
Implement `Sync` for `process::Command on unix and vxworks Closes #72387. r? @cuviper
2020-05-22Implement `Sync` for `process::Command on unix and vxworksLeSeulArtichaut-2/+4
2020-05-22Rollup merge of #72123 - jsgf:stabilize-arg0, r=sfacklerRalf Jung-1/+1
Stabilize process_set_argv0 feature for Unix This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows, but as far as I know nobody has. That can be done separately. Tracking issue: #66510
2020-05-17abort_internal is safeRalf Jung-2/+2
2020-05-12Stabilize process_set_argv0 feature for UnixJeremy Fitzhardinge-1/+1
This stabilizes process_set_argv0 targeting 1.45.0. It has been useful in practice and seems useful as-is. The equivalent feature could be implemented for Windows, but as far as I know nobody has. That can be done separately. Tracking issue: #66510
2020-05-07Rollup merge of #71980 - steveklabnik:warnings-fixes, r=Mark-SimulacrumDylan DPC-0/+6
Allow a few warnings. On Windows, these types were causing warnings to be emitted during the build. These types are allowed to not have idiomatic names, so the warning should be supressed.
2020-05-07Allow a few warnings.Steve Klabnik-0/+6
On Windows, these types were causing warnings to be emitted during the build. These types are allowed to not have idiomatic names, so the warning should be supressed.
2020-05-06Rollup merge of #71921 - RalfJung:open-mode, r=hanna-kruppeDylan DPC-0/+4
explain the types used in the open64 call Fixes https://github.com/rust-lang/rust/issues/71915, where I learned about this quirk. I don't actually know what I am talking about here. ;)
2020-05-05explain the types used in the open64 callRalf Jung-0/+4
2020-05-05rely on rdlock/wrlock not returning anything but the specified error codesRalf Jung-2/+6
2020-05-04edit Mutex commentRalf Jung-4/+6
2020-05-04explain our rwlock implementation (and fix a potential data race)Ralf Jung-20/+24
2020-05-04expand comment on default mutex behaviorRalf Jung-3/+7
2020-04-26Fix stragglersSteven Fackler-5/+5
2020-04-26Update nameSteven Fackler-24/+24
2020-04-26Add Read/Write::can_read/write_vectoredSteven Fackler-0/+91
When working with an arbitrary reader or writer, code that uses vectored operations may end up being slower than code that copies into a single buffer when the underlying reader or writer doesn't actually support vectored operations. These new methods allow you to ask the reader or witer up front if vectored operations are efficiently supported. Currently, you have to use some heuristics to guess by e.g. checking if the read or write only accessed the first buffer. Hyper is one concrete example of a library that has to do this dynamically: https://github.com/hyperium/hyper/blob/0eaf304644a396895a4ce1f0146e596640bb666a/src/proto/h1/io.rs#L582-L594
2020-04-15Use fcntl() to set nonblock for solarish socketsPatrick Mooney-0/+8
The ioctl(FIONBIO) method of setting a file descriptor to be non-blocking does not notify the underlying resource in the same way that fcntl(F_SETFL, O_NONBLOCK) does on illumos and Solaris.
2020-04-14Add illumos triplePatrick Mooney-13/+64
Co-Authored-By: Jason King <jason.brian.king@gmail.com> Co-Authored-By: Joshua M. Clulow <jmc@oxide.computer>
2020-04-03Rollup merge of #70597 - vakaras:thread_new_double_free_bug_fix, r=AmanieuMazdak Farrokhzad-7/+14
Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new While working on concurrency support for Miri, I found that the `libstd::syn::unix::Thread::new` method has two potential problems: double-free and undefined behaviour. **Double-free** could occur if the following events happened (credit for pointing this out goes to @RalfJung): 1. The call to `pthread_create` successfully launched a new thread that executed to completion and deallocated `p`. 2. The call to `pthread_attr_destroy` returned a non-zero value causing the `assert_eq!` to panic. 3. Since `mem::forget(p)` was not yet executed, the destructor of `p` would be executed and cause a double-free. As far as I understand, this code also violates the stacked-borrows aliasing rules and thus would result in **undefined behaviour** if these rules were adopted. The problem is that the ownership of `p` is passed to the newly created thread before the call to `mem::forget`. Since the call to `mem::forget` is still a call, it counts as a use of `p` and triggers UB. This pull request changes the code to use `mem::ManuallyDrop` instead of `mem::forget`. As a consequence, in case of a panic, `p` would be potentially leaked, which while undesirable is probably better than double-free or undefined behaviour.
2020-04-01In Thread::new, add a comment that a panic could cause a memory leak.Vytautas Astrauskas-1/+4
2020-03-31Use Box::into_raw instead of ManuallyDrop in Thread::new.Vytautas Astrauskas-9/+4
2020-03-31Inline start_thread into its callers.Vytautas Astrauskas-4/+6
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-08 21:53:06 +0000