about summary refs log tree commit diff
path: root/src/libstd/sys
AgeCommit message (Collapse)AuthorLines
2019-11-30Rollup merge of #66705 - pitdicker:atomic_mut_ptr, r=KodrAusMazdak Farrokhzad-5/+5
Atomic as_mut_ptr I encountered the following pattern a few times: In Rust we use some atomic type like `AtomicI32`, and an FFI interface exposes this as `*mut i32` (or some similar `libc` type). It was not obvious to me if a just transmuting a pointer to the atomic was acceptable, or if this should use a cast that goes through an `UnsafeCell`. See https://github.com/rust-lang/rust/issues/66136#issuecomment-557802477 Transmuting the pointer directly: ```rust let atomic = AtomicI32::new(1); let ptr = &atomic as *const AtomicI32 as *mut i32; unsafe { ffi(ptr); } ``` A dance with `UnsafeCell`: ```rust let atomic = AtomicI32::new(1); unsafe { let ptr = (&*(&atomic as *const AtomicI32 as *const UnsafeCell<i32>)).get(); ffi(ptr); } ``` Maybe in the end both ways could be valid. But why not expose a direct method to get a pointer from the standard library? An `as_mut_ptr` method on atomics can be safe, because only the use of the resulting pointer is where things can get unsafe. I documented its use for FFI, and "Doing non-atomic reads and writes on the resulting integer can be a data race." The standard library could make use this method in a few places in the WASM module. cc @RalfJung as you answered my original question.
2019-11-30Auto merge of #66887 - dtolnay:rollup-uxowp8d, r=Centrilbors-2285/+2527
Rollup of 4 pull requests Successful merges: - #66818 (Format libstd/os with rustfmt) - #66819 (Format libstd/sys with rustfmt) - #66820 (Format libstd with rustfmt) - #66847 (Allow any identifier as format arg name) Failed merges: r? @ghost
2019-11-29Format libstd/sys with rustfmtDavid Tolnay-2285/+2527
This commit applies rustfmt with rust-lang/rust's default settings to files in src/libstd/sys *that are not involved in any currently open PR* to minimize merge conflicts. THe list of files involved in open PRs was determined by querying GitHub's GraphQL API with this script: https://gist.github.com/dtolnay/aa9c34993dc051a4f344d1b10e4487e8 With the list of files from the script in outstanding_files, the relevant commands were: $ find src/libstd/sys -name '*.rs' \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ rg libstd/sys outstanding_files | xargs git checkout -- Repeating this process several months apart should get us coverage of most of the rest of the files. To confirm no funny business: $ git checkout $THIS_COMMIT^ $ git show --pretty= --name-only $THIS_COMMIT \ | xargs rustfmt --edition=2018 --unstable-features --skip-children $ git diff $THIS_COMMIT # there should be no difference
2019-11-29really_init cmdline args on MiriRalf Jung-1/+7
2019-11-29Auto merge of #66547 - leo60228:procfs-fallback, r=dtolnaybors-1/+29
Fallback to .init_array when no arguments are available on glibc Linux Linux is one of the only platforms where `std::env::args` doesn't work in a cdylib.
2019-11-26Fix spelling typosBrian Wignall-3/+3
2019-11-25Rollup merge of #66512 - jsgf:process-argv0, r=Dylan-DPCPietro Albini-10/+35
Add unix::process::CommandExt::arg0 This allows argv[0] to be overridden on the executable's command-line. This also makes the program executed independent of argv[0]. Does Fuchsia have the same semantics? I'm assuming so. Addresses: #66510
2019-11-24Use as_mut_ptr instead of castsPaul Dicker-5/+5
2019-11-22Make std::sys::unix::args::init a no-op on glibc Linuxleo60228-2/+8
2019-11-22Document ARGV_INIT_ARRAYleo60228-0/+2
2019-11-22Set .init_array priorityleo60228-1/+1
I'm not entirely sure *why*, but this fixed a problem I was having.
2019-11-22Use .init_array section on glibcleo60228-0/+20
2019-11-20Rollup merge of #66553 - hermitcore:hermit, r=rkruppeMazdak Farrokhzad-1/+1
remove HermitCore leftovers from sys/unix HermitCore support is already moved to the directory "sys/hermit". => remove leftovers
2019-11-19HermitCore support is moved to sys/hermit, remove obsolete statement in sys/unixStefan Lankes-1/+1
2019-11-19Add unix::process::CommandExt::arg0Jeremy Fitzhardinge-10/+35
This allows argv[0] to be overridden on the executable's command-line. This also makes the program executed independent of argv[0]. Does Fuchsia have the same semantics? Addresses: #66510
2019-11-15Rollup merge of #66350 - hermitcore:hermit, r=rkruppeMazdak Farrokhzad-0/+3
protect creation of destructors by a mutex - add on HermitCore an additional lock to protect static data
2019-11-14Auto merge of #66378 - rkruppe:revert-pr-65134, r=pnkfelixbors-4/+0
Revert #65134 To stop giving people on nightly reasons to `allow(improper_ctypes)` while tweaks to the lint are being prepared. cc #66220
2019-11-13Revert "Auto merge of #65134 - ↵Robin Kruppe-4/+0
davidtwco:issue-19834-improper-ctypes-in-extern-C-fn, r=rkruppe" This reverts commit 3f0e16473de5ec010f44290a8c3ea1d90e0ad7a2, reversing changes made to 61a551b4939ec1d5596e585351038b8fbd0124ba.
2019-11-13Rollup merge of #66166 - GuillaumeGomez:rename-rustdoc-to-doc, r=QuietMisdreavusYuki Okushi-17/+17
rename cfg(rustdoc) into cfg(doc) Needed by https://github.com/rust-lang/rust/pull/61351 r? @QuietMisdreavus
2019-11-13Merge remote-tracking branch 'rust-lang/master' into hermitStefan Lankes-2/+8
2019-11-13protect creation of destructors by a mutexStefan Lankes-0/+3
add on HermizCore an additional lock to protect static data
2019-11-06rename cfg(rustdoc) into cfg(doc)Guillaume Gomez-17/+17
2019-11-06Auto merge of #65134 - davidtwco:issue-19834-improper-ctypes-in-extern-C-fn, ↵bors-0/+4
r=rkruppe improper_ctypes: `extern "C"` fns cc #19834. Fixes #65867. This pull request implements the change [described in this comment](https://github.com/rust-lang/rust/issues/19834#issuecomment-466671572). cc @rkruppe @varkor @shepmaster
2019-11-06Rollup merge of #66092 - niacat:master, r=nagisaMazdak Farrokhzad-1/+2
Use KERN_ARND syscall for random numbers on NetBSD, same as FreeBSD. This system call is present on all supported NetBSD versions and provides an endless stream of non-blocking random data from the kernel's ChaCha20-based CSPRNG. It doesn't require a file like `/dev/urandom` to be opened. The system call is documented here (under kern.arandom): https://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-7.0 And defined here: https://nxr.netbsd.org/xref/src/sys/sys/sysctl.h#273 The semantics are the same as FreeBSD so reading 256 bytes per call is fine. Similar change for getrandom crate: rust-random/getrandom#115
2019-11-05Rollup merge of #66091 - Wind-River:master_xyz, r=cramertjPietro Albini-1/+2
Implemented the home_dir for VxWorks Use HOME's value if it is set; otherwise return NONE.
2019-11-05libstd: allow `improper_ctypes` in `sys/sgx`David Wood-0/+4
Signed-off-by: David Wood <david@davidtw.co>
2019-11-05Rollup merge of #65905 - cuviper:doc-unix-mode, r=Dylan-DPCPietro Albini-4/+4
[doc] fixes for unix/vxworks `OpenOptionsExt::mode`
2019-11-04Use any() in code shared between FreeBSD and NetBSDnia-1/+1
2019-11-04Use KERN_ARND syscall for random numbers on NetBSD, same as FreeBSD.nia-1/+2
This system call is present on all supported NetBSD versions and provides an endless stream of non-blocking random data from the kernel's ChaCha20-based CSPRNG. It doesn't require a file descriptor to be opened. The system call is documented here (under kern.arandom): https://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-7.0 And defined here: https://nxr.netbsd.org/xref/src/sys/sys/sysctl.h#273 The semantics are the same as FreeBSD so reading 256 bytes per call is fine. Similar change for getrandom crate: rust-random/getrandom#115
2019-11-04Implemented the home_dir for VxWorksUmesh Kalappa-1/+2
2019-10-29vxWorks: remove all code related to UNIX socket as it is not supported by ↵BaoshanPang-1828/+60
vxWorks
2019-10-28[doc] fix the reference to using `OpenOptions::open`Josh Stone-2/+2
2019-10-28[doc] add a possessive apostrophe in `OpenOptionsExt::mode`Josh Stone-2/+2
2019-10-26Auto merge of #65167 - hermitcore:rusty-hermit, r=alexcrichtonbors-30/+2255
Redesign the interface to the unikernel HermitCore We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs. We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
2019-10-26Rollup merge of #65810 - raoulstrackx:ac_mitigation, r=nagisaYuki Okushi-1/+7
SGX: Clear additional flag on enclave entry An attacker could set both the AC flag in CR0 as in rflags. This causes the enclave to perform an AEX upon a misaligned memory access, and an attacker learns some information about the internal enclave state. The AC flag in rflags is copied from userspace upon an enclave entry. Upon AEX it is copied and later restored. This patch forces the rflag.AC bit to be reset right after an enter.
2019-10-25forgot pushfq/popqfq: fixedRaoul Strackx-0/+2
2019-10-25cleaning up codeRaoul Strackx-9/+4
2019-10-25removed unnecessary pushRaoul Strackx-1/+0
2019-10-25Rollup merge of #65685 - oxalica:statx-eperm, r=alexcrichtonMazdak Farrokhzad-42/+55
Fix check of `statx` and handle EPERM Should fix #65662 https://github.com/rust-lang/rust/issues/65662#issuecomment-544593939 > I think a reasonable solution might be to do something like try to stat AT_CWD initially and if that fails with EPERM or ENOSYS we disable the syscall entirely, otherwise it's cached as always good to use. r? @alexcrichton
2019-10-25Merge branch 'master' into rusty-hermit, resolve conflictsStefan Lankes-14/+13
2019-10-23Rollup merge of #64178 - mati865:clippy, r=scottmcmMazdak Farrokhzad-10/+9
More Clippy fixes for alloc, core and std Continuation of https://github.com/rust-lang/rust/pull/63805
2019-10-23Rollup merge of #65617 - newpavlov:patch-2, r=alexcrichtonYuki Okushi-4/+4
Fix WASI sleep impl Closes #65607 @sunfishcode Is it fine to use 0 for the `identifier` field? What is this field used for?
2019-10-23Some tweaksoxalica-49/+44
2019-10-22Apply clippy::while_let_on_iterator suggestionsMateusz Mikuła-2/+1
2019-10-22Apply clippy::needless_return suggestionsMateusz Mikuła-8/+8
2019-10-22Merge branch 'master' into rusty-hermitStefan Lankes-34/+2
2019-10-22Fix check of `statx`oxalica-16/+34
2019-10-21fixed ac vulnerabilityRaoul Strackx-0/+10
2019-10-20Merge branch 'master' into rusty-hermitStefan Lankes-18/+239
2019-10-20move interface to the unikernel in the crate hermit-abiStefan Lankes-113/+54
=> simplifies the maintenance of the interface