25'ten fazla konu seçemezsiniz Konular bir harf veya rakamla başlamalı, kısa çizgiler ('-') içerebilir ve en fazla 35 karakter uzunluğunda olabilir.
 
 
 
 
 
 

190 satır
6.3 KiB

  1. BoringSSL Style Guide.
  2. BoringSSL usually follows the Google C++ style guide, found below. The
  3. rest of this document describes differences and clarifications on top
  4. of the base guide.
  5. https://google-styleguide.googlecode.com/svn/trunk/cppguide.html
  6. Legacy code.
  7. As a derivative of OpenSSL, BoringSSL contains a lot of legacy code
  8. that does not follow this style guide. Particularly where public API
  9. is concerned, balance consistency within a module with the benefits of
  10. a given rule. Module-wide deviations on naming should be respected
  11. while integer and return value conventions take precedence over
  12. consistency.
  13. Some modules have seen few changes, so they still retain the original
  14. indentation style for now. When editing these, try to retain the
  15. original style. For Emacs, doc/c-indentation.el from OpenSSL may be
  16. helpful in this.
  17. Language.
  18. The majority of the project is in C, so C++-specific rules in the
  19. Google style guide do not apply. Support for C99 features depends on
  20. our target platforms. Typically, Chromium's target MSVC is the most
  21. restrictive.
  22. Variable declarations in the middle of a function are allowed.
  23. Comments should be /* C-style */ for consistency.
  24. When declaration pointer types, * should be placed next to the variable
  25. name, not the type. So
  26. uint8_t *ptr;
  27. not
  28. uint8_t* ptr;
  29. Rather than malloc() and free(), use the wrappers OPENSSL_malloc() and
  30. OPENSSL_free(). Use the standard C assert() function freely.
  31. For new constants, prefer enums when the values are sequential and typed
  32. constants for flags. If adding values to an existing set of #defines, continue
  33. with #define.
  34. Formatting.
  35. Single-statement blocks are not allowed. All conditions and loops must
  36. use braces:
  37. if (foo) {
  38. do_something();
  39. }
  40. not
  41. if (foo)
  42. do_something();
  43. Integers.
  44. Prefer using explicitly-sized integers where appropriate rather than
  45. generic C ones. For instance, to represent a byte, use uint8_t, not
  46. unsigned char. Likewise, represent a two-byte field as uint16_t, not
  47. unsigned short.
  48. Sizes are represented as size_t.
  49. Within a struct that is retained across the lifetime of an SSL
  50. connection, if bounds of a size are known and it's easy, use a smaller
  51. integer type like uint8_t. This is a "free" connection footprint
  52. optimization for servers. Don't make code significantly more complex
  53. for it, and do still check the bounds when passing in and out of the
  54. struct. This narrowing should not propagate to local variables and
  55. function parameters.
  56. When doing arithmetic, account for overflow conditions.
  57. Except with platform APIs, do not use ssize_t. MSVC lacks it, and
  58. prefer out-of-band error signaling for size_t (see Return values).
  59. Naming.
  60. Define structs with typedef named TYPE_NAME. The corresponding struct
  61. should be named struct type_name_st.
  62. Name public functions as MODULE_function_name, unless the module
  63. already uses a different naming scheme for legacy reasons. The module
  64. name should be a type name if the function is a method of a particular
  65. type.
  66. Some types are allocated within the library while others are
  67. initialized into a struct allocated by the caller, often on the
  68. stack. Name these functions TYPE_NAME_new/TYPE_NAME_free and
  69. TYPE_NAME_init/TYPE_NAME_cleanup, respectively.
  70. If a variable is the length of a pointer value, it has the suffix
  71. _len. An output parameter is named out or has an out_ prefix. For
  72. instance, For instance:
  73. uint8_t *out,
  74. size_t *out_len,
  75. const uint8_t *in,
  76. size_t in_len,
  77. Name public headers like include/openssl/evp.h with header guards like
  78. OPENSSL_HEADER_EVP_H. Name internal headers like crypto/ec/internal.h
  79. with header guards like OPENSSL_HEADER_EC_INTERNAL_H.
  80. Name enums like unix_hacker_t. For instance:
  81. enum should_free_handshake_buffer_t {
  82. free_handshake_buffer,
  83. dont_free_handshake_buffer,
  84. };
  85. Return values.
  86. As even malloc may fail in BoringSSL, the vast majority of functions
  87. will have a failure case. Functions should return int with one on
  88. success and zero on error. Do not overload the return value to both
  89. signal success/failure and output an integer. For example:
  90. OPENSSL_EXPORT int CBS_get_u16(CBS *cbs, uint16_t *out);
  91. If a function needs more than a true/false result code, define an enum
  92. rather than arbitrarily assigning meaning to int values.
  93. If a function outputs a pointer to an object on success and there are no
  94. other outputs, return the pointer directly and NULL on error.
  95. Parameters.
  96. Where not constrained by legacy code, parameter order should be:
  97. 1. context parameters
  98. 2. output parameters
  99. 3. input parameters
  100. For example,
  101. /* CBB_add_asn sets |*out_contents| to a |CBB| into which the contents of an
  102. * ASN.1 object can be written. The |tag| argument will be used as the tag for
  103. * the object. It returns one on success or zero on error. */
  104. OPENSSL_EXPORT int CBB_add_asn1(CBB *cbb, CBB *out_contents, uint8_t tag);
  105. Documentation.
  106. All public symbols must have a documentation comment in their header
  107. file. The style is based on that of Go. The first sentence begins with
  108. the symbol name, optionally prefixed with "A" or "An". Apart from the
  109. initial mention of symbol, references to other symbols or parameter
  110. names should be surrounded by |pipes|. Don't be too verbose, but do
  111. document success and failure behaviors.
  112. /* EVP_DigestVerifyUpdate appends |len| bytes from |data| to the data which
  113. * will be verified by |EVP_DigestVerifyFinal|. It returns one on success and
  114. * zero otherwise. */
  115. OPENSSL_EXPORT int EVP_DigestVerifyUpdate(EVP_MD_CTX *ctx, const void *data,
  116. size_t len);
  117. Explicitly mention any surprising edge cases or deviations from common
  118. return value patterns in legacy functions.
  119. /* RSA_private_encrypt encrypts |flen| bytes from |from| with the private key in
  120. * |rsa| and writes the encrypted data to |to|. The |to| buffer must have at
  121. * least |RSA_size| bytes of space. It returns the number of bytes written, or
  122. * -1 on error. The |padding| argument must be one of the |RSA_*_PADDING|
  123. * values. If in doubt, |RSA_PKCS1_PADDING| is the most common.
  124. *
  125. * WARNING: this function is dangerous because it breaks the usual return value
  126. * convention. Use |RSA_sign_raw| instead. */
  127. OPENSSL_EXPORT int RSA_private_encrypt(int flen, const uint8_t *from,
  128. uint8_t *to, RSA *rsa, int padding);
  129. Document private functions in their internal.h header or, if static,
  130. where defined.