| /third_party/rust/crates/rustix/.github/workflows/ |
| D | main.yml | 6 - main
13 runs-on: ubuntu-latest
15 - uses: actions/checkout@v3
18 - uses: ./.github/actions/install-rust
21 - run: cargo fmt --all -- --check
25 runs-on: ${{ matrix.os }}
30 - build: stable
31 os: ubuntu-latest
33 - build: nightly
34 os: ubuntu-latest
[all …]
|
| /third_party/node/ |
| D | SECURITY.md | 35 against all supported Node.js versions. Once confirmed, a list of all affected
37 problems. Fixes are prepared for all supported releases.
75 the correct use of Node.js APIs.
87 that are accepted through the use of Node.js APIs and
90 * HTTP APIs (all flavors) server APIs.
92 that are created through the use of Node.js APIs and
97 * HTTP APIs (all flavors) client APIs.
98 * DNS APIs.
99 3. Consumers of data protected through the use of Node.js APIs (for example
100 people who have access to data encrypted through the Node.js crypto APIs).
[all …]
|
| /third_party/icu/docs/userguide/icu/ |
| D | design.md | 1 ---
6 ---
7 <!--
10 -->
16 {: .no_toc .text-delta }
21 ---
34 2. [Data-driven services](#data-driven-services)
35 3. [ICU threading models and the open and close model](#icu-threading-model-and-open-and-close-mode…
36 4. [Cloning customization](#cloning-customization)
37 5. [Error handling](#error-handling)
[all …]
|
| D | posix.md | 1 ---
6 ---
7 <!--
10 -->
16 {: .no_toc .text-delta }
21 ---
23 ## Migration from Standard C and POSIX APIs
25 The ISO C and POSIX standards define a number of APIs for string handling and
27 initially designed before Unicode/ISO 10646 were developed, and the POSIX APIs
30 This chapter discusses C/POSIX APIs with their problems, and shows which ICU
[all …]
|
| /third_party/mbedtls/docs/architecture/psa-migration/ |
| D | strategy.md | 10 G2. Allow isolation of long-term secrets (for example, private keys).
11 G3. Allow isolation of short-term secrets (for example, TLS session keys).
15 As of Mbed TLS 3.2, most of (G1) and all of (G2) is implemented when
17 needs to be changed to use new APIs. For a more detailed account of what's
18 implemented, see `docs/use-psa-crypto.md`, where new APIs are about (G2), and
28 Compile-time options
31 We currently have a few compile-time options that are relevant to the migration:
33 - `MBEDTLS_PSA_CRYPTO_C` - enabled by default, controls the presence of the PSA
34 Crypto APIs.
35 - `MBEDTLS_USE_PSA_CRYPTO` - disabled by default (enabled in "full" config),
[all …]
|
| D | psa-legacy-bridges.md | 1 Bridges between legacy and PSA crypto APIs
8 …sed on [requirements](#requirements), we [analyze gaps](#gap-analysis) and [API design](#api-desig…
10 …iners. See the companion document [“Transitioning to the PSA API”](../../psa-transition.md) for a …
20 Mbed TLS 3.x supports two cryptographic APIs:
27 …ptography will be provided by a separate project [TF-PSA-Crypto](https://github.com/Mbed-TLS/TF-PS…
31 …3.6. Mbed TLS 3.6 includes both PSA and legacy APIs covering largely overlapping ground. Many lega…
35 ### Why mix APIs?
45 …arge projects, it is impractical to rewrite a significant part of the code all at once. (For examp…
49 … is, built with support for both APIs. Therefore no special effort is necessary to allow an applic…
51 …APIs as part of the implementation of the same feature. From an informal analysis of typical appli…
[all …]
|
| /third_party/EGL/extensions/KHR/ |
| D | EGL_KHR_image_base.txt | 27 Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at
59 sharing 2D arrays of image data between client APIs, the EGLImage.
63 the application and associated client APIs.
68 client APIs, presumably a 2D array of image data
70 EGLImage source: An object or sub-object originally created in
72 in OpenGL-ES, or a VGImage in OpenVG) which is used as
76 texture object in OpenGL-ES or a VGImage in OpenVG)
77 from a previously-created EGLImage
79 EGLImage sibling: The set of all EGLImage targets (in all
104 * target resources (inside client APIs).
[all …]
|
| /third_party/skia/third_party/externals/egl-registry/extensions/KHR/ |
| D | EGL_KHR_image_base.txt | 27 Copyright (c) 2008-2013 The Khronos Group Inc. Copyright terms at
59 sharing 2D arrays of image data between client APIs, the EGLImage.
63 the application and associated client APIs.
68 client APIs, presumably a 2D array of image data
70 EGLImage source: An object or sub-object originally created in
72 in OpenGL-ES, or a VGImage in OpenVG) which is used as
76 texture object in OpenGL-ES or a VGImage in OpenVG)
77 from a previously-created EGLImage
79 EGLImage sibling: The set of all EGLImage targets (in all
104 * target resources (inside client APIs).
[all …]
|
| /third_party/vk-gl-cts/external/vulkan-docs/src/appendices/ |
| D | VK_KHR_external_memory.txt | 1 // Copyright 2016-2021 The Khronos Group, Inc.
3 // SPDX-License-Identifier: CC-BY-4.0
10 2016-10-20
14 - Interacts with `apiext:VK_KHR_dedicated_allocation`.
15 - Interacts with `apiext:VK_NV_dedicated_allocation`.
16 - Promoted to Vulkan 1.1 Core
18 - Jason Ekstrand, Intel
19 - Ian Elliot, Google
20 - Jesse Hall, Google
21 - Tobias Hector, Imagination Technologies
[all …]
|
| D | VK_KHR_external_memory.adoc | 1 // Copyright 2016-2024 The Khronos Group Inc.
3 // SPDX-License-Identifier: CC-BY-4.0
10 2016-10-20
14 - Interacts with `apiext:VK_KHR_dedicated_allocation`.
15 - Interacts with `apiext:VK_NV_dedicated_allocation`.
17 - Faith Ekstrand, Intel
18 - Ian Elliott, Google
19 - Jesse Hall, Google
20 - Tobias Hector, Imagination Technologies
21 - James Jones, NVIDIA
[all …]
|
| /third_party/rust/crates/rustix/ |
| D | CONTRIBUTING.md | 9 features. A special feature, `all-apis` enables all APIs, which is useful
13 cargo test --features=all-apis
18 enable the `use-libc` feature:
21 cargo test --features=all-apis,use-libc
26 getting all the `cfg`s lined up to get everything compiling on all the
|
| /third_party/libbpf/docs/ |
| D | libbpf_overview.rst | 1 .. SPDX-License-Identifier: GPL-2.0
7 libbpf is a C-based library containing a BPF loader that takes compiled BPF
13 The following are the high-level features supported by libbpf:
15 * Provides high-level and low-level APIs for user space programs to interact
16 with BPF programs. The low-level APIs wrap all the bpf system call
17 functionality, which is useful when users need more fine-grained control
22 * Provides BPF-side APIS, including BPF helper definitions, BPF maps support,
24 * Supports BPF CO-RE mechanism, enabling BPF developers to write portable
32 BPF App Lifecycle and libbpf APIs
37 variables are shared between all BPF programs, which allows them to cooperate on
[all …]
|
| /third_party/libwebsockets/READMEs/ |
| D | README.crypto-apis.md | 1 # Lws Crypto Apis
5 
10 backends... it's as simple as rebuilding lws with `-DLWS_WITH_MBEDTLS=0`
18 The `JW` apis use the generic apis (`lws_genrsa_`, etc) to get the crypto tasks
19 done, so anything they can do you can also get done using the generic apis.
20 The main difference is that with the generic apis, you must instantiate the
21 correct types and use type-specfic apis. With the `JW` apis, there is only
22 one interface for all operations, with the details hidden in the api and
25 Because of this, the `JW` apis are often preferred because they give you
35 - SHA1
[all …]
|
| D | README.jwt.md | 6 and JWT validation. All of the common algorithms like ES512 are supported
7 along with JWK generation and handling apis.
9 The build options needed are `-DLWS_WITH_JOSE=1` `-DLWS_WITH_GENCRYPTO=1`.
11 Underlying JOSE primitives are exposed as apis, some JWT specific primitives
12 and finally a JWT-via http cookie level creation apis each building on top of
15 The higher level APIs are provided additionally because they have the most
17 not using the latest cookie security options; the provided APIs handle that
18 centrally for you. If your needs vary from what the higher level apis are
19 doing, you can cut-and-paste out those implementations and create your own
20 using the public lower level apis.
[all …]
|
| /third_party/mbedtls/docs/ |
| D | use-psa-crypto.md | 1 This document describes the compile-time configuration option
5 - makes the X.509 and TLS libraries use PSA for cryptographic operations as
7 - enables new APIs for using keys handled by PSA Crypto, such as
9 "New APIs / API extensions" below.
12 ----------------------
21 for ECDSA, ECDH and EC J-PAKE in those modules. However, note that even with
28 - `MBEDTLS_PSA_CRYPTO_C` enables the implementation of the PSA Crypto API.
29 When it is enabled, `psa_xxx()` APIs are available and you must call
31 modules in the library (non-PSA crypto APIs, X.509, TLS) may or may not use
33 non-PSA functions, unless explicitly documented (TLS 1.3).
[all …]
|
| D | driver-only-builds.md | 3 built-in implementation of those algorithms), from a user's perspective.
10 ----------------------
14 guide](psa-driver-example-and-guide.md) for information on writing a
18 the following compile-time configuration options enabled:
20 - `MBEDTLS_PSA_CRYPTO_C` (enabled by default) - this enables PSA Crypto.
21 - `MBEDTLS_USE_PSA_CRYPTO` (disabled by default) - this makes PK, X.509 and
24 [the dedicated document](use-psa-crypto.md) for details.)
25 - `MBEDTLS_PSA_CRYPTO_CONFIG` (disabled by default) - this enables
29 TLS](proposed/psa-conditional-inclusion-c.md) for details.
33 - Define the corresponding `PSA_WANT` macro in `psa/crypto_config.h` - this
[all …]
|
| /third_party/rust/crates/clap/src/ |
| D | _faq.rs | 4 //! 1. [How does `clap` compare to structopt?](#how-does-clap-compare-to-structopt)
5 …2. [What are some reasons to use `clap`? (The Pitch)](#what-are-some-reasons-to-use-clap-the-pitch)
6 …me reasons *not* to use `clap`? (The Anti Pitch)](#what-are-some-reasons-not-to-use-clap-the-anti-…
7 //! 4. [Reasons to use `clap`](#reasons-to-use-clap)
8 … [How many approaches are there to create a parser?](#how-many-approaches-are-there-to-create-a-pa…
9 //! 3. [When should I use the builder vs derive APIs?](#when-should-i-use-the-builder-vs-derive-api…
10 //! 4. [Why is there a default subcommand of help?](#why-is-there-a-default-subcommand-of-help)
15 //! in a critical or harsh manner. All the argument parsing libraries out there (to
17 //! comes down to personal taste when all other factors are equal. When in doubt,
18 //! try them all and pick one that you enjoy :). There's plenty of room in the Rust
[all …]
|
| /third_party/libwebsockets/ |
| D | changelog | 2 ---------
7 - Add full CBOR stream parsing and writing support, with huge
8 amount of test vectors and resumable printf type write apis
9 See ./READMEs/README.cbor-lecp.md
10 - Add COSE key and signing / validation support with huge amount of
14 See ./READMEs/README.cbor-cose.md
15 - JIT Trust: for constrained devices, provides a way to determine the
19 See ./READMEs/README.jit-trust.md
20 - Add support for client Netscape cookie jar with caching
21 - Secure Streams: issue LWSSSCS_EVENT_WAIT_CANCELLED state() when
[all …]
|
| /third_party/node/doc/contributing/maintaining/ |
| D | maintaining-http.md | 5 [technical priorities](https://github.com/nodejs/node/blob/HEAD/doc/contributing/technical-prioriti…
8 [Next-10](https://github.com/nodejs/next-10)
9 [mini-summit](https://github.com/nodejs/next-10/blob/main/meetings/summit-jan-2022.md)
14 The key elements of our strategy for future HTTP APIs are:
16 * APIs should be HTTP protocol independent (support HTTP1, HTTP2, etc.).
17 * APIs should be transport protocol independent (TCP, QUIC, etc.).
18 * APIs should provide good defaults that perform well.
19 * Client/server APIs should be consistent and allow easy integration.
20 * Common requirements like piping out from client API to server APIs should be
22 * For both the Client and Server there is a need for multiple APIs, with each
[all …]
|
| /third_party/icu/docs/processes/release/tasks/ |
| D | docs.md | 1 ---
3 title: APIs & Docs
7 ---
9 <!--
12 -->
14 # APIs & Docs
18 {: .no_toc .text-delta }
23 ---
30 see** [ICU-8862](https://unicode-org.atlassian.net/browse/ICU-8862) **).**
33 `sudo apt-get install doxygen`
[all …]
|
| /third_party/icu/docs/userguide/dev/ |
| D | codingguidelines.md | 1 ---
6 ---
7 <!--
10 -->
16 {: .no_toc .text-delta }
21 ---
53 See [Adoption of Objects](#adoption-of-objects) for further information.
63 } else if(pBiDi==nullptr || (length=pBiDi->length)<=0) {
76 Note: *Callers* (as opposed to implementers) of ICU APIs can simplify their code
98 return 0; // or calling UErrorCode-less
[all …]
|
| /third_party/openGLES/ |
| D | README.adoc | 1 // Copyright 2017-2021 The Khronos Group Inc.
2 // SPDX-License-Identifier: CC-BY-4.0
4 = OpenGL-Registry
7 == OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
10 APIs - OpenGL, OpenGL ES, and OpenGL SC. It includes API specifications;
11 specifications of Khronos- and vendor-approved extensions; header files
16 the KhronosGroup/OpenGL-Refpages repository.
21 change the Registry, propose a pull request against the OpenGL-Registry
33 The OpenGL-Registry repository isn't the right place to report problems with
37 the https://github.com/KhronosGroup/OpenGL-API repository.
[all …]
|
| /third_party/skia/third_party/externals/opengl-registry/ |
| D | README.adoc | 1 = OpenGL-Registry
4 == OpenGL, OpenGL ES, and OpenGL ES-SC API and Extension Registry
7 APIs - OpenGL, OpenGL ES, and OpenGL SC. It includes API specifications;
8 specifications of Khronos- and vendor-approved extensions; header files
13 the KhronosGroup/OpenGL-Refpages repository.
18 change the Registry, propose a pull request against the OpenGL-Registry
30 The OpenGL-Registry repository isn't the right place to report problems with
34 the https://github.com/KhronosGroup/OpenGL-API repository.
37 tracker in the https://github.com/KhronosGroup/OpenGL-GLSL repository.
44 OpenGL-Registry issue tracker.
[all …]
|
| /third_party/rust/crates/cxx/syntax/ |
| D | types.rs | 16 pub all: OrderedSet<&'a Type>, field
31 pub fn collect(cx: &mut Errors, apis: &'a [Api]) -> Self { in collect()
32 let mut all = OrderedSet::new(); in collect() localVariable
44 fn visit<'a>(all: &mut OrderedSet<&'a Type>, ty: &'a Type) { in collect()
54 CollectTypes(all).visit_type(ty); in collect()
63 for api in apis { in collect()
69 // All other cases of duplicate identifiers are reported as an error. in collect()
86 visit(&mut all, &field.ty); in collect()
93 all.insert(repr_type); in collect()
95 #[cfg(feature = "experimental-enum-variants-from-header")] in collect()
[all …]
|
| /third_party/icu/docs/userguide/strings/ |
| D | utf-8.md | 1 ---
3 title: UTF-8
6 ---
7 <!--
10 -->
12 # UTF-8
14 *Note: This page is only relevant for C/C++. In Java, all strings are encoded in
15 UTF-16, except for conversion from bytes to strings (via InputStreamReader or
18 While most of ICU works with UTF-16 strings and uses data structures optimized
19 for UTF-16, there are APIs that facilitate working with UTF-8, or are optimized
[all …]
|