| /third_party/musl/porting/liteos_a/user/src/misc/ |
| D | wordexp.c | 27 static int do_wordexp(const char *s, wordexp_t *we, int flags) in do_wordexp() argument
42 if (flags & WRDE_REUSE) wordfree(we); in do_wordexp()
87 wc = we->we_wordc; in do_wordexp()
88 wv = we->we_wordv; in do_wordexp()
93 if (we->we_offs > SIZE_MAX/sizeof(void *)/4) in do_wordexp()
95 i += we->we_offs; in do_wordexp()
97 we->we_offs = 0; in do_wordexp()
153 we->we_wordv = wv; in do_wordexp()
154 we->we_wordc = i; in do_wordexp()
157 if (wv) for (i=we->we_offs; i; i--) in do_wordexp()
[all …]
|
| /third_party/musl/src/misc/ |
| D | wordexp.c | 26 static int do_wordexp(const char *s, wordexp_t *we, int flags) in do_wordexp() argument
41 if (flags & WRDE_REUSE) wordfree(we); in do_wordexp()
86 wc = we->we_wordc; in do_wordexp()
87 wv = we->we_wordv; in do_wordexp()
92 if (we->we_offs > SIZE_MAX/sizeof(void *)/4) in do_wordexp()
94 i += we->we_offs; in do_wordexp()
96 we->we_offs = 0; in do_wordexp()
152 we->we_wordv = wv; in do_wordexp()
153 we->we_wordc = i; in do_wordexp()
156 if (wv) for (i=we->we_offs; i; i--) in do_wordexp()
[all …]
|
| /third_party/unity/docs/ |
| D | ThrowTheSwitchCodingStandard.md | 4 we try to follow these standards to unify our contributors' code into a cohesive
7 and we'll try to be polite when we notice yours.
15 our standard simple because we also believe that we can only expect someone to
21 Before we get into details on syntax, let's take a moment to talk about our
28 Our philosophy is "support every compiler we can". Most often, this means that
29 we aim for writing C code that is standards compliant (often C89... that seems
34 standard library functions. A lot of Unity is configurable and we have worked
40 compile to a particular location. It's just what we do, because we like
43 Speaking of having things Just Work™, that's our second philosophy. By that, we
44 mean that we do our best to have EVERY configuration option have a logical
[all …]
|
| /third_party/cJSON/tests/unity/docs/ |
| D | ThrowTheSwitchCodingStandard.md | 4 we try to follow these standards to unify our contributors' code into a cohesive
7 and we'll try to be polite when we notice yours.
15 our standard simple because we also believe that we can only expect someone to
21 Before we get into details on syntax, let's take a moment to talk about our
28 Our philosophy is "support every compiler we can". Most often, this means that
29 we aim for writing C code that is standards compliant (often C89... that seems
34 standard library functions. A lot of Unity is configurable and we have worked
40 compile to a particular location. It's just what we do, because we like
43 Speaking of having things Just Work™, that's our second philosophy. By that, we
44 mean that we do our best to have EVERY configuration option have a logical
[all …]
|
| /third_party/python/Objects/stringlib/ |
| D | stringlib_find_two_way_notes.txt | 41 and if a mismatch occurs, we jump ahead by the amount matched plus 1.
55 Why are we allowed to do this? Because we cut the needle very
57 we have
66 cut, then the following alignments do not work, so we can skip them:
86 right, then we could run into something like this:
91 The same argument holds that we can skip ahead by 4, so long as
102 true, we need them to be true for all possible '?' values. We thus
108 Once we have ensured the right part matches, we scan the left part
109 (order doesn't matter, but traditionally right-to-left), and if we
110 find a mismatch, we jump ahead by
[all …]
|
| /third_party/flutter/flutter/packages/flutter_tools/lib/src/commands/ |
| D | update_packages.dart | 132 // ensure we only get flutter/packages
152 // If the checksum is invalid or missing, we can just ask them run to run
169 // we need to run update-packages to recapture the transitive deps.
202 …irectory directory in packages) { // these are all the directories with pubspec.yamls we care about
213 // If we've seen the dependency before, make sure that we are
216 // pointing at the version of a package we get from the Dart SDK
217 // that we download with Flutter), by SDK (e.g. the "flutter"
220 // This makes sure that we don't import a package in two different
232 // Remember this dependency by name so we can look it up again.
234 // Normal dependencies are those we get from pub. The others we
[all …]
|
| /third_party/littlefs/ |
| D | DESIGN.md | 61 For ROM, this means we need to keep our design simple and reuse code paths
62 were possible. For RAM we have a stronger requirement, all RAM usage is
71 however they often share and borrow feature from each other. If we look at
72 power-loss resilience and wear leveling, we can narrow these down to a handful
75 1. First we have the non-resilient, block based filesystems, such as [FAT] and
109 2. In a completely different direction, we have logging filesystems, such as
126 Logging filesystem are beautifully elegant. With a checksum, we can easily
131 The main downside is performance. If we look at garbage collection, the
144 filesystem. [ext4] and [NTFS] are good examples. Here, we take a normal
145 block based filesystem and add a bounded log where we note every change
[all …]
|
| /third_party/typescript/tests/baselines/reference/ |
| D | functionsMissingReturnStatementsAndExpressions.errors.txt | 25 // Fine since we are typed void.
29 // Fine since we are typed void.
34 // Fine since we are typed void and return undefined
39 // Fine since we are typed void and return null
49 // Fine since we are typed any and return undefined
54 // Fine since we are typed any and return null
59 // Fine since we consist of a single throw statement.
64 // Fine since we consist of a single throw statement.
69 // Fine since we consist of a single throw statement.
74 // Not fine, since we can *only* consist of a single throw statement
[all …]
|
| D | functionsMissingReturnStatementsAndExpressions.types | 25 // Fine since we are typed void.
31 // Fine since we are typed void.
38 // Fine since we are typed void and return undefined
46 // Fine since we are typed void and return null
61 // Fine since we are typed any and return undefined
69 // Fine since we are typed any and return null
77 // Fine since we consist of a single throw statement.
85 // Fine since we consist of a single throw statement.
93 // Fine since we consist of a single throw statement.
101 // Not fine, since we can *only* consist of a single throw statement
[all …]
|
| D | functionsMissingReturnStatementsAndExpressions.symbols | 24 // Fine since we are typed void.
30 // Fine since we are typed void.
37 // Fine since we are typed void and return undefined
45 // Fine since we are typed void and return null
59 // Fine since we are typed any and return undefined
67 // Fine since we are typed any and return null
74 // Fine since we consist of a single throw statement.
82 // Fine since we consist of a single throw statement.
90 // Fine since we consist of a single throw statement.
98 // Not fine, since we can *only* consist of a single throw statement
[all …]
|
| /third_party/skia/site/docs/user/ |
| D | color.md | 9 What we mean by color management
14 D50. And we can infer from that same description how to transform from that
33 in color management, and we need to divide it out if it's multiplied in
42 type called SkColorSpaceXformSteps. You'll see it as 5 steps there: we always
48 Whenever we're about to do some drawing we look at which of those steps we
49 really need to do. Any step that's a fundamental no-op we skip:
60 * if we've skipped 3 and 4 already, we can skip 2 and 5 any time the transfer
63 * if we've skipped all of 2-5, we can skip 1 and 6 if we were going to do
70 with that same color space, we'll notice we can skip all six steps. Sometimes
84 (Order matters there.) The gist is, we assume any untagged sources are sRGB.
[all …]
|
| /third_party/gstreamer/gstplugins_bad/gst/audiovisualizers/ |
| D | README | 14 * we have a couple of drawing helpers in gstdrawhelpers.h
15 (would be nice if we could use cairo)
18 * some more we could add:
24 - would be nice to use a generic 3x3 matrix operation, we don't run inplace
26 - this way we could also blur the background
27 - we need to handle visualizer that don't draw with alpha:
34 gst-plugins-good/gst/monoscope -> blend into what we have in wavescope
35 - it keeps an array of the values we just showed last[width]
49 - we could have a bouncing line as a base, like a quix:
53 - we would need to rotate, stretch and clip the waveform drawing to fit the
[all …]
|
| /third_party/mesa3d/src/intel/genxml/ |
| D | README | 11 other hand, most compiler recognize that the template struct we
17 2) For some types we need to have overlapping bit fields. For
27 flexibility in how we combine things. In the case of overlapping
28 fields (the u32 and float case), if we only set one of them in
38 Once we have the pack function it allows us to hook in various
39 transformations and validation as we go from template struct to dwords
43 overflowing values to the fields, but we've of course had lots of
44 cases where we make mistakes and write overflowing values. With
45 the pack function, we can actually assert on that and catch it at
49 float to a u32, but we also convert from bool to bits, from
[all …]
|
| /third_party/flutter/skia/third_party/externals/libjpeg-turbo/ |
| D | example.txt | 69 * For this example, we'll assume that this data structure matches the way
70 * our application has stored the image in memory, so we can just pass a
97 * (see the second half of this file for an example). But here we just
114 * address which we place into the link field in cinfo.
117 /* Now we can initialize the JPEG compression object. */
123 /* Here we use the library-supplied code to send compressed data to a
136 /* First we supply a description of the input image.
149 * Here we just illustrate the use of quality (quantization table) scaling:
155 /* TRUE ensures that we will write a complete interchange-JPEG file.
163 /* Here we use the library's state variable cinfo.next_scanline as the
[all …]
|
| /third_party/libjpeg-turbo/ |
| D | example.txt | 69 * For this example, we'll assume that this data structure matches the way
70 * our application has stored the image in memory, so we can just pass a
97 * (see the second half of this file for an example). But here we just
114 * address which we place into the link field in cinfo.
117 /* Now we can initialize the JPEG compression object. */
123 /* Here we use the library-supplied code to send compressed data to a
136 /* First we supply a description of the input image.
149 * Here we just illustrate the use of quality (quantization table) scaling:
155 /* TRUE ensures that we will write a complete interchange-JPEG file.
163 /* Here we use the library's state variable cinfo.next_scanline as the
[all …]
|
| /third_party/alsa-lib/src/ |
| D | userfile.c | 40 wordexp_t we; in snd_user_file() local
44 err = wordexp(file, &we, WRDE_NOCMD); in snd_user_file()
47 wordfree(&we); in snd_user_file()
50 if (we.we_wordc == 1) in snd_user_file()
52 wordfree(&we); in snd_user_file()
57 *result = strdup(we.we_wordv[0]); in snd_user_file()
58 wordfree(&we); in snd_user_file()
|
| /third_party/nghttp2/doc/sources/ |
| D | tutorial-server.rst | 4 In this tutorial, we are going to write a single-threaded, event-based
27 example program, when creating the ``SSL_CTX`` object, we store the
29 allocated buffer. This is safe because we only create one ``SSL_CTX``
92 identifier. In this tutorial, we advertise the specific HTTP/2
96 OpenSSL implementation, we just assign the pointer to the NPN buffers
97 we filled in earlier. The NPN callback function is set to the
100 In ``alpn_select_proto_cb()``, we use `nghttp2_select_next_protocol()`
135 A single HTTP/2 session can have multiple streams. To manage them, we
196 Here we create the ``http2_session_data`` object. The connection's
249 Here we validate that HTTP/2 is negotiated, and if not, drop
[all …]
|
| D | tutorial-client.rst | 4 In this tutorial, we are going to write a very primitive HTTP/2
23 application protocol over TLS. In this tutorial, we use the
44 we have to instruct OpenSSL SSL_CTX to use ALPN, which we'll talk
70 Here we see ``SSL_CTX_get_alpn_protos()`` function call. We instructs
71 OpenSSL to notify the server that we support h2, ALPN identifier for
190 Here we validate that HTTP/2 is negotiated, and if not, drop
194 events, we just simply tear down the connection.
197 handshake has completed successfully. After this we're ready to begin
230 Since we are creating a client, we use `nghttp2_session_client_new()`
258 Here we specify SETTINGS_MAX_CONCURRENT_STREAMS as 100. This is not
[all …]
|
| /third_party/flutter/flutter/dev/integration_tests/ios_add2app/ios_add2app/ |
| D | FullScreenViewController.m | 25 // Note that if we were doing things that might cause the VC
27 // we shouldn't do this. But in this case we know we're
29 // If we needed Flutter to tell us when we could actually go away,
30 // we'd need to communicate over a method channel with it.
|
| /third_party/rust/crates/aho-corasick/src/packed/teddy/ |
| D | README.md | 18 regex engine, since we rarely care about the performance difference between
69 Finally, we get to Teddy. If the above literature review is complete, then it
72 what we want in a general purpose regex engine. Again, the algorithm appears
90 The details to make this work are quite clever. First, we must choose how to
93 any substring in the set being searched. In this implementation, we use the
125 Now, all we need to do is figure out how to represent this map in vector space
127 we can make is to represent our patterns as bit fields occupying a single
135 How do we perform lookup though? It turns out that SSSE3 introduced a very cool
143 If we could somehow cause `B` to contain our 16 byte block from the haystack,
144 and if `A` could contain our bitmasks, then we'd end up with something like
[all …]
|
| /third_party/flutter/flutter/examples/layers/raw/ |
| D | touch_input.dart | 14 // First we create a PictureRecorder to record the commands we're going to
19 // Next, we create a canvas from the recorder. The canvas is an interface
34 // When we're done issuing painting commands, we end the recording an receive
35 // a Picture, which is an immutable record of the commands we've issued. You
64 // When we're done recording the scene, we call build() to obtain an immutable
65 // record of the scene we've recorded.
80 // The pointer packet contains a number of pointer movements, which we iterate
84 // If the pointer went down, we change the color of the circle to blue.
86 // Rather than calling paint() synchronously, we ask the engine to
91 // Similarly, if the pointer went up, we change the color of the circle to
[all …]
|
| /third_party/ltp/docparse/ |
| D | README.md | 46 tests in parallel we need to know which system resources are utilized by a
47 given test, as obviously we cannot run two tests that monopolize the same
48 resource. In some cases we would also need to partition the system resource
49 accordingly, e.g. if we have two memory stress tests running at the same time
50 we will need to cap each of these tests on half of the available memory, or
72 supposed to run, this means that we have to guess some upper limit on how long
74 for all testcases or whole suite or even larger. This means that we are wasting
75 time in the case that the test ends up stuck and we could have failed it much
78 supposed to crash a kernel under a minute is exported to the testrunner we can
85 runtest files. Once this system is in place we will have a list of all tests
[all …]
|
| /third_party/vk-gl-cts/external/vulkan-docs/src/appendices/ |
| D | VK_EXT_device_memory_report.adoc | 41 So we can avoid the extra implementation complexity used to accommodate the
44 2) Can we extend and use the existing internal allocation callbacks instead
53 That may be doable for the extensions we know about, but not for ones we do
56 But even for ones we know about, since apps can provide a different set of
59 for pool object, but not just those), we would have to dynamically allocate
68 Though we might be able to handle this with additional
69 elink:VkInternalAllocationType values, for import/export we do want to be
77 That was deliberate: there is a real possibility we will want to get extra
79 As one example, currently this reports only physical allocations, but we
107 4) Should we use an array of callback for the layers to intercept instead of
[all …]
|
| D | VK_EXT_device_memory_report.txt | 41 So we can avoid the extra implementation complexity used to accommodate the
44 2) Can we extend and use the existing internal allocation callbacks instead
53 That may be doable for the extensions we know about, but not for ones we do
56 But even for ones we know about, since apps can provide a different set of
59 for pool object, but not just those), we would have to dynamically allocate
68 Though we might be able to handle this with additional
69 elink:VkInternalAllocationType values, for import/export we do want to be
77 That was deliberate: there is a real possibility we will want to get extra
79 As one example, currently this reports only physical allocations, but we
107 4) Should we use an array of callback for the layers to intercept instead of
[all …]
|
| /third_party/lwip/src/netif/ppp/ |
| D | PPPD_FOLLOWUP | 5 is getting low on their Git repository, meaning that we can follow what
8 So, here is the pppd follow up, so that we don't get away too far from pppd.
13 This has nothing to do with pppd, but we merged some good patch from
16 - LCP adaptive echo, so that we don't send LCP echo request if we
65 feature is disabled in the port, so we don't care about the new
73 Again, we are not running as a heavy process, so all exit() or _exit() calls
88 Only concern changes on RP-PPPoE plugin, which we don't use.
106 Patch for sys-linux.c, which we don't use.
126 Again, we are not running scripts.
132 Again, we are not using the RP-PPPoE plugin.
[all …]
|