README.OpenSource修改
Created-by: dragonswordy
Commit-by: ljy9810
Merged-by: openharmony_ci
Description: <!-- Thank you for submitting a PR!
We have the contribution guide, please read it if you are new here!
<https://github.com/rust-lang/libc/blob/main/CONTRIBUTING.md>
Please fill out the below template.
-->
# Description
<!-- Add a short description about what this change does -->
https://gitcode.com/openharmony/third_party_rust_unicode-ident/issues/3
# Sources
<!-- All API changes must have permalinks to headers. Common sources:
* Linux uapi https://github.com/torvalds/linux/tree/master/include/uapi
* Glibc https://github.com/bminor/glibc
* Musl https://github.com/bminor/musl
* Apple XNU https://github.com/apple-oss-distributions/xnu
* Android https://cs.android.com/android/platform/superproject/main
After navigating to the relevant file, click the triple dots and select "copy
permalink" if on GitHub, or l-r (links->commit) for the Android source to get a
link to the current version of the header.
If sources are closed, link to documentation or paste relevant C definitions.
-->
# Checklist
<!-- Please make sure the following has been done before submitting a PR,
or mark it as a draft if you are not sure. -->
- [ ] Relevant tests in `libc-test/semver` have been updated
- [ ] No placeholder or unstable values like `*LAST` or `*MAX` are
included (see [#3131](https://github.com/rust-lang/libc/issues/3131))
- [ ] Tested locally (`cd libc-test && cargo test --target mytarget`);
especially relevant for platforms that may not be checked in CI
<!-- labels: is this PR a breaking change? If not, we can probably get it in a
0.2 release. Just uncomment the following:
@rustbot label +stable-nominated
-->
See merge request: openharmony/third_party_rust_libc!16
libc升级到0.2.180版本
Created-by: dragonswordy
Commit-by: ljy9810
Merged-by: openharmony_ci
Description: Thanks for considering submitting a PR!
https://gitcode.com/openharmony/third_party_rust_libc/issues/9
Here's a checklist for things that will be checked during review or continuous integration.
- \[ ] Edit corresponding file(s) under `libc-test/semver` when you add/remove item(s)
- \[ ] `rustc ci/style.rs && ./style src`
- \[ ] `cd libc-test && cargo test` (This might fail on your env due to environment difference between your env and CI. Ignore failures if you are not sure.)
- \[ ] Your PR that bumps up the crate version doesn't contain any other changes
Delete this line and everything above before opening your PR.
See merge request: openharmony/third_party_rust_libc!15
Add missing string-to-number functions from ISO C
These should be the observable API changes:
- ISO C90 function `atol()` is added to all `fuchsia`, `unix`, `vxworks`, `wasi`, and `windows` targets.
- ISO C90 function `atof()` is added to `android`, `redox`, and `vxworks`.
- ISO C99 functions `atoll()`, `strtoll()`, and `strtoull()` are added to all `fuchsia`, `unix`, `vxworks`, `wasi`, and `windows` targets.
Also, I wasn't exactly sure where to insert the new functions, so I just tried to place them near related functions.
Try readding all inotify flags
Adds back some inotify flags that were once too new, but it appears the inexorable process of time has made the tests pass now.
redox: long is 32-bits on 32-bit systems
This ensures that 32-bit systems use i32 for c_long and u32 for c_ulong.
I have also adjusted off_t and time_t to be `long long`, which is what they are in `relibc` now.
Enable copy_file_range on FreeBSD
PR #2479 did this, but only in the freebsd13 and freebsd14 modules, which was incorrect. Those modules should only be used for functions that change across FreeBSD versions, and therefore need different ELF symbol versions. Functions that were newly added since FreeBSD 11 can still go in the base freebsd module. It will cause no problems for them to be there, and users will see an error at link time if they try to use such a function in an environment that is too old to support it.
PR #2479 did this, but only in the freebsd13 and freebsd14 modules,
which was incorrect. Those modules should only be used for functions
that change across FreeBSD versions, and therefore need different ELF
symbol versions. Functions that were newly added since FreeBSD 11 can
still go in the base freebsd module. It will cause no problems for them
to be there, and users will see an error at link time if they try to
use such a function in an environment that is too old to support it.
openharmony_ci