Restoring authorship annotation for <orivej@yandex-team.ru>. Commit 2 of 2.

4 files changed, 114 insertions, 114 deletions

diff --git a/contrib/libs/grpc/third_party/upb/CONTRIBUTING.md b/contrib/libs/grpc/third_party/upb/CONTRIBUTING.md
index d5edbe8eee..2f866b4e29 100644
--- a/contrib/libs/grpc/third_party/upb/CONTRIBUTING.md
+++ b/contrib/libs/grpc/third_party/upb/CONTRIBUTING.md
@@ -1,7 +1,7 @@
-## <a name="cla"></a> Signing the CLA 
- 
-Please sign the [Google Contributor License Agreement 
-(CLA)](https://cla.developers.google.com/) 
-before sending pull requests. For any code changes to be 
-accepted, the CLA must be signed. It's a quick process, I 
-promise! 
+## <a name="cla"></a> Signing the CLA
+
+Please sign the [Google Contributor License Agreement
+(CLA)](https://cla.developers.google.com/)
+before sending pull requests. For any code changes to be
+accepted, the CLA must be signed. It's a quick process, I
+promise!
diff --git a/contrib/libs/grpc/third_party/upb/DESIGN.md b/contrib/libs/grpc/third_party/upb/DESIGN.md
index 7ae10f449b..a7a8a28451 100644
--- a/contrib/libs/grpc/third_party/upb/DESIGN.md
+++ b/contrib/libs/grpc/third_party/upb/DESIGN.md
@@ -1,72 +1,72 @@
- 
-μpb Design 
----------- 
- 
-μpb has the following design goals: 
- 
-- C89 compatible. 
-- small code size (both for the core library and generated messages). 
-- fast performance (hundreds of MB/s). 
-- idiomatic for C programs. 
-- easy to wrap in high-level languages (Python, Ruby, Lua, etc) with 
-  good performance and all standard protobuf features. 
-- hands-off about memory management, allowing for easy integration 
-  with existing VMs and/or garbage collectors. 
-- offers binary ABI compatibility between apps, generated messages, and 
-  the core library (doesn't require re-generating messages or recompiling 
-  your application when the core library changes). 
-- provides all features that users expect from a protobuf library 
-  (generated messages in C, reflection, text format, etc.). 
-- layered, so the core is small and doesn't require descriptors. 
-- tidy about symbol references, so that any messages or features that 
-  aren't used by a C program can have their code GC'd by the linker. 
-- possible to use protobuf binary format without leaking message/field 
-  names into the binary. 
- 
-μpb accomplishes these goals by keeping a very small core that does not contain 
-descriptors.  We need some way of knowing what fields are in each message and 
-where they live, but instead of descriptors, we keep a small/lightweight summary 
-of the .proto file.  We call this a `upb_msglayout`.  It contains the bare 
-minimum of what we need to know to parse and serialize protobuf binary format 
-into our internal representation for messages, `upb_msg`. 
- 
-The core then contains functions to parse/serialize a message, given a `upb_msg*` 
-and a `const upb_msglayout*`. 
- 
-This approach is similar to [nanopb](https://github.com/nanopb/nanopb) which 
-also compiles message definitions to a compact, internal representation without 
-names.  However nanopb does not aim to be a fully-featured library, and has no 
-support for text format, JSON, or descriptors.  μpb is unique in that it has a 
-small core similar to nanopb (though not quite as small), but also offers a 
-full-featured protobuf library for applications that want reflection, text 
-format, JSON format, etc. 
- 
-Without descriptors, the core doesn't have access to field names, so it cannot 
-parse/serialize to protobuf text format or JSON.  Instead this functionality 
-lives in separate modules that depend on the module implementing descriptors. 
-With the descriptor module we can parse/serialize binary descriptors and 
-validate that they follow all the rules of protobuf schemas. 
- 
-To provide binary compatibility, we version the structs that generated messages 
-use to create a `upb_msglayout*`.  The current initializers are 
-`upb_msglayout_msginit_v1`, `upb_msglayout_fieldinit_v1`, etc.  Then 
-`upb_msglayout*` uses these as its internal representation.  If upb changes its 
-internal representation for a `upb_msglayout*`, it will also include code to 
-convert the old representation to the new representation.  This will use some 
-more memory/CPU at runtime to convert between the two, but apps that statically 
-link μpb will never need to worry about this. 
- 
-TODO 
----- 
- 
-1. revise our generated code until it is in a state where we feel comfortable 
-   committing to API/ABI stability for it.  In particular there is an open 
-   question of whether non-ABI-compatible field accesses should have a 
-   fastpath different from the ABI-compatible field access. 
-1. Add missing features (maps, extensions, unknown fields). 
-1. Flesh out C++ wrappers. 
-1. *(lower-priority)*: revise all of the existing encoders/decoders and 
-   handlers.  We probably will want to keep handlers, since they let us decouple 
-   encoders/decoders from `upb_msg`, but we need to simplify all of that a LOT. 
-   Likely we will want to make handlers only per-message instead of per-field, 
-   except for variable-length fields. 
+
+μpb Design
+----------
+
+μpb has the following design goals:
+
+- C89 compatible.
+- small code size (both for the core library and generated messages).
+- fast performance (hundreds of MB/s).
+- idiomatic for C programs.
+- easy to wrap in high-level languages (Python, Ruby, Lua, etc) with
+  good performance and all standard protobuf features.
+- hands-off about memory management, allowing for easy integration
+  with existing VMs and/or garbage collectors.
+- offers binary ABI compatibility between apps, generated messages, and
+  the core library (doesn't require re-generating messages or recompiling
+  your application when the core library changes).
+- provides all features that users expect from a protobuf library
+  (generated messages in C, reflection, text format, etc.).
+- layered, so the core is small and doesn't require descriptors.
+- tidy about symbol references, so that any messages or features that
+  aren't used by a C program can have their code GC'd by the linker.
+- possible to use protobuf binary format without leaking message/field
+  names into the binary.
+
+μpb accomplishes these goals by keeping a very small core that does not contain
+descriptors.  We need some way of knowing what fields are in each message and
+where they live, but instead of descriptors, we keep a small/lightweight summary
+of the .proto file.  We call this a `upb_msglayout`.  It contains the bare
+minimum of what we need to know to parse and serialize protobuf binary format
+into our internal representation for messages, `upb_msg`.
+
+The core then contains functions to parse/serialize a message, given a `upb_msg*`
+and a `const upb_msglayout*`.
+
+This approach is similar to [nanopb](https://github.com/nanopb/nanopb) which
+also compiles message definitions to a compact, internal representation without
+names.  However nanopb does not aim to be a fully-featured library, and has no
+support for text format, JSON, or descriptors.  μpb is unique in that it has a
+small core similar to nanopb (though not quite as small), but also offers a
+full-featured protobuf library for applications that want reflection, text
+format, JSON format, etc.
+
+Without descriptors, the core doesn't have access to field names, so it cannot
+parse/serialize to protobuf text format or JSON.  Instead this functionality
+lives in separate modules that depend on the module implementing descriptors.
+With the descriptor module we can parse/serialize binary descriptors and
+validate that they follow all the rules of protobuf schemas.
+
+To provide binary compatibility, we version the structs that generated messages
+use to create a `upb_msglayout*`.  The current initializers are
+`upb_msglayout_msginit_v1`, `upb_msglayout_fieldinit_v1`, etc.  Then
+`upb_msglayout*` uses these as its internal representation.  If upb changes its
+internal representation for a `upb_msglayout*`, it will also include code to
+convert the old representation to the new representation.  This will use some
+more memory/CPU at runtime to convert between the two, but apps that statically
+link μpb will never need to worry about this.
+
+TODO
+----
+
+1. revise our generated code until it is in a state where we feel comfortable
+   committing to API/ABI stability for it.  In particular there is an open
+   question of whether non-ABI-compatible field accesses should have a
+   fastpath different from the ABI-compatible field access.
+1. Add missing features (maps, extensions, unknown fields).
+1. Flesh out C++ wrappers.
+1. *(lower-priority)*: revise all of the existing encoders/decoders and
+   handlers.  We probably will want to keep handlers, since they let us decouple
+   encoders/decoders from `upb_msg`, but we need to simplify all of that a LOT.
+   Likely we will want to make handlers only per-message instead of per-field,
+   except for variable-length fields.
diff --git a/contrib/libs/grpc/third_party/upb/LICENSE b/contrib/libs/grpc/third_party/upb/LICENSE
index 25e71011d3..da939845db 100644
--- a/contrib/libs/grpc/third_party/upb/LICENSE
+++ b/contrib/libs/grpc/third_party/upb/LICENSE
@@ -1,26 +1,26 @@
- 
-Copyright (c) 2009-2011, Google Inc. 
-All rights reserved. 
- 
-Redistribution and use in source and binary forms, with or without 
-modification, are permitted provided that the following conditions are met: 
- 
-    * Redistributions of source code must retain the above copyright 
-      notice, this list of conditions and the following disclaimer. 
-    * Redistributions in binary form must reproduce the above copyright 
-      notice, this list of conditions and the following disclaimer in the 
-      documentation and/or other materials provided with the distribution. 
-    * Neither the name of Google Inc. nor the names of any other 
-      contributors may be used to endorse or promote products 
-      derived from this software without specific prior written permission. 
- 
-THIS SOFTWARE IS PROVIDED BY GOOGLE INC. ``AS IS'' AND ANY EXPRESS OR IMPLIED 
-WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
-MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO 
-EVENT SHALL GOOGLE INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
-SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, 
-PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR 
-BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER 
-IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
-ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
-POSSIBILITY OF SUCH DAMAGE. 
+
+Copyright (c) 2009-2011, Google Inc.
+All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+    * Redistributions of source code must retain the above copyright
+      notice, this list of conditions and the following disclaimer.
+    * Redistributions in binary form must reproduce the above copyright
+      notice, this list of conditions and the following disclaimer in the
+      documentation and/or other materials provided with the distribution.
+    * Neither the name of Google Inc. nor the names of any other
+      contributors may be used to endorse or promote products
+      derived from this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY GOOGLE INC. ``AS IS'' AND ANY EXPRESS OR IMPLIED
+WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
+EVENT SHALL GOOGLE INC. BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
+PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
+IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGE.
diff --git a/contrib/libs/grpc/third_party/upb/ya.make b/contrib/libs/grpc/third_party/upb/ya.make
index e8128e8034..1dc7487601 100644
--- a/contrib/libs/grpc/third_party/upb/ya.make
+++ b/contrib/libs/grpc/third_party/upb/ya.make
@@ -8,7 +8,7 @@ LICENSE(
     BSD-3-Clause AND
     Public-Domain
 )
- 
+
 LICENSE_TEXTS(.yandex_meta/licenses.list.txt)
 
 ADDINCL(
@@ -19,8 +19,8 @@ ADDINCL(
 
 NO_COMPILER_WARNINGS()
 
-NO_RUNTIME() 
- 
+NO_RUNTIME()
+
 IF (OS_LINUX OR OS_DARWIN)
     CFLAGS(
         -DGRPC_POSIX_FORK_ALLOW_PTHREAD_ATFORK=1
@@ -28,12 +28,12 @@ IF (OS_LINUX OR OS_DARWIN)
 ENDIF()
 
 SRCS(
-    upb/decode.c 
-    upb/encode.c 
-    upb/msg.c 
-    upb/port.c 
-    upb/table.c 
-    upb/upb.c 
+    upb/decode.c
+    upb/encode.c
+    upb/msg.c
+    upb/port.c
+    upb/table.c
+    upb/upb.c
 )
 
 END()