Lines Matching refs:in
8 Much of the code in libxl does not yet follow this coding style
9 document in every respect. However, new code is expected to conform.
19 In this case, the new code should conform to the prevailing style in
28 "libxl memory management" in libxl.h.
98 then checking it in a separate statement:
102 * If a resource is freed in the main body of the function (for
103 example, in a loop), the corresponding variable has to be reset to
116 applicable _r function parameter (or equivalent). Do not test `rc' in
119 The uses of the single-line formatting in the examples above are
127 Nontrivial data structures (in structs) should come with an idempotent
138 All long-running operations in libxl need to use the asynchronous
139 operation machinery. Consult the programmer documentation in
143 The code for asynchronous operations should be laid out in
146 function in the file. This will normally involve predeclaring the
150 Control flow arrangements in asynchronous operations should be made as
155 When inventing a new sub-operation in asynchronous code, consider
159 An ao-suboperation state structure should contain, in this order:
160 * fields that the caller must fill in, and which are,
175 documented in comments, if it is nontrivial.
179 * Physically include the sub-operation state struct in your
184 _init method) in your own _init method.
185 * Unconditionally cancel or destroy the sub-operation in your own
197 Of course, the most important aspect in any coding style is whitespace.
203 Libxenlight indents are four spaces. Tabs are never used, except in
214 - Tabs are rendered badly in patches, causing off-by-one errors in almost
227 xterms and use vi in all of them. The best way to punish them is to
230 characters, +/- diff characters, and so on, in emails.
273 libxenlight and libxl_ when exported in libxl.h.
301 the blocks in an if...else chain have braces, or none of them do.