1Sereal::Decoder(3) User Contributed Perl Documentation Sereal::Decoder(3)
2
6 Sereal::Decoder - Fast, compact, powerful binary deserialization
7
9 use Sereal::Decoder
10 qw(decode_sereal sereal_decode_with_object scalar_looks_like_sereal);
11 my $decoder = Sereal::Decoder->new({...options...});
13 my $structure;
15 $decoder->decode($blob, $structure); # deserializes into $structure
16 # or if you don't have references to the top level structure, this works, too:
18 $structure = $decoder->decode($blob);
19 # alternatively functional interface: (See Sereal::Performance)
21 sereal_decode_with_object($decoder, $blob, $structure);
22 $structure = sereal_decode_with_object($decoder, $blob);
23 # much slower functional interface with no persistent objects:
25 decode_sereal($blob, {... options ...}, $structure);
26 $structure = decode_sereal($blob, {... options ...});
27 # Not a full validation, but just a quick check for a reasonable header:
29 my $is_likely_sereal = scalar_looks_like_sereal($some_string);
30 # or:
31 $is_likely_sereal = $decoder->looks_like_sereal($some_string);
32
34 This library implements a deserializer for an efficient, compact-
35 output, and feature-rich binary protocol called Sereal. Its sister
36 module Sereal::Encoder implements an encoder for this format. The two
37 are released separately to allow for independent and safer upgrading.
38 The Sereal protocol versions that are compatible with this decoder
40 implementation are currently protocol versions 1, 2, 3 and 4. As it
41 stands, it will refuse to attempt to decode future versions of the
42 protocol, but if necessary there is likely going to be an option to
43 decode the parts of the input that are compatible with version 4 of the
44 protocol. The protocol was designed to allow for this.
45 The protocol specification and many other bits of documentation can be
47 found in the github repository. Right now, the specification is at
48 <https://github.com/Sereal/Sereal/blob/master/sereal_spec.pod>, there
49 is a discussion of the design objectives in
50 <https://github.com/Sereal/Sereal/blob/master/README.pod>, and the
51 output of our benchmarks can be seen at
52 <https://github.com/Sereal/Sereal/wiki/Sereal-Comparison-Graphs>.
53
55 new
56 Constructor. Optionally takes a hash reference as first parameter. This
57 hash reference may contain any number of options that influence the
58 behaviour of the encoder.
59 Currently, the following options are recognized, none of them are on by
61 default.
62 refuse_snappy
64 If set, the decoder will refuse Snappy-compressed input data. This can
66 be desirable for robustness. See the section "ROBUSTNESS" below.
67 refuse_objects
69 If set, the decoder will refuse deserializing any objects in the input
71 stream and instead throw an exception. Defaults to off. See the section
72 "ROBUSTNESS" below.
73 no_bless_objects
75 If set, the decoder will deserialize any objects in the input stream
77 but without blessing them. Defaults to off. See the section
78 "ROBUSTNESS" below.
79 no_thaw_objects
81 If set, the decoder will deserialize frozen objects in the objects
83 stream as an array ref of arguments that would be passed into the THAW
84 subroutine instead of calling THAW itself.
85 validate_utf8
87 If set, the decoder will refuse invalid UTF-8 byte sequences. This is
89 off by default, but it's strongly encouraged to be turned on if you're
90 dealing with any data that has been encoded by an external source (e.g.
91 http cookies).
92 max_recursion_depth
94 "Sereal::Decoder" is recursive. If you pass it a Sereal document that
96 is deeply nested, it will eventually exhaust the C stack. Therefore,
97 there is a limit on the depth of recursion that is accepted. It
98 defaults to 10000 nested calls. You may choose to override this value
99 with the "max_recursion_depth" option. Beware that setting it too high
100 can cause hard crashes.
101 Do note that the setting is somewhat approximate. Setting it to 10000
103 may break at somewhere between 9997 and 10003 nested structures
104 depending on their types.
105 max_num_hash_entries
107 If set to a non-zero value (default: 0), then "Sereal::Decoder" will
109 refuse to deserialize any hash/dictionary (or hash-based object) with
110 more than that number of entries. This is to be able to respond quickly
111 to any future hash-collision attacks on Perl's hash function, and also
112 the memory exhaustion attacks on Sereal itself. For a gentle
113 introduction to the topic from the cryptographic point of view, see
114 <http://en.wikipedia.org/wiki/Collision_attack>.
115 max_num_array_entries
117 If set to a non-zero value (default: 0), then "Sereal::Decoder" will
119 refuse to deserialize any array with more than that number of entries.
120 This is to be able to respond quickly to any future memory exhaustion
121 attacks on Sereal.
122 max_string_length
124 If set to a non-zero value (default: 0), then "Sereal::Decoder" will
126 refuse to deserialize any string with more than that number of
127 characters. This is to be able to respond quickly to any future memory
128 exhaustion attacks on Sereal.
129 max_uncompressed_size
131 If set to a non-zero value (default: 0), then "Sereal::Decoder" will
133 refuse to deserialize any blob with a size that exceds the value when
134 uncompressed. This is to be able to respond quickly to any future
135 memory exhaustion attacks on Sereal.
136 incremental
138 If set to a non-zero value (default: 0), then "Sereal::Decoder" will
140 destructively parse Sereal documents out of a variable. Every time a
141 Sereal document is successfully parsed it is removed from the front of
142 the string it is parsed from.
143 This means you can do this:
145 while (length $buffer) {
147 my $data= decode_sereal($buffer,{incremental=>1});
148 }
149 alias_smallint
151 If set to a true value then "Sereal::Decoder" will share integers from
153 -16 to 15 (encoded as either SRL_HDR_NEG and SRL_HDR_POS) as read-only
154 aliases to a common SV.
155 The result of this may be significant space savings in data structures
157 with many integers in the specified range. The cost is more memory used
158 by the decoder and a very modest speed penalty when deserializing.
159 Note this option changes the structure of the dumped data. Use with
161 caution.
162 See also the "alias_varint_under" option.
164 alias_varint_under
166 If set to a true positive integer smaller than 16 then this option is
168 similar to setting "alias_smallint" and causes all integers from -16 to
169 15 to be shared as read-only aliases to the same SV, except that this
170 treatment ALSO applies to SRL_HDR_VARINT. If set to a value larger than
171 16 then this applies to all varints varints under the value set. (In
172 general SRL_HDR_VARINT is used only for integers larger than 15, and
173 SRL_HDR_NEG and SRL_HDR_POS are used for -16 to -1 and 0 to 15
174 respectively.)
175 In simple terms if you want to share values larger than 16 then you
177 should use this option, if you want to share only values in the -16 to
178 15 range then you should use the "alias_smallint" option instead.
179 The result of this may be significant space savings in data structures
181 with many integers in the desire range. The cost is more memory used by
182 the decoder and a very modest speed penalty when deserializing.
183 Note this option changes the structure of the dumped data. Use with
185 caution.
186 use_undef
188 If set to a true value then this any undef value to be deserialized as
190 PL_sv_undef. This may change the structure of the data structure being
191 dumped, do not enable this unless you know what you are doing.
192 set_readonly
194 If set to a true value then the output will be completely readonly
196 (deeply).
197 set_readonly_scalars
199 If set to a true value then scalars in the output will be readonly
201 (deeply). References won't be readonly.
202
204 decode
205 Given a byte string of Sereal data, the "decode" call deserializes that
206 data structure. The result can be obtained in one of two ways: "decode"
207 accepts a second parameter, which is a scalar to write the result to,
208 AND "decode" will return the resulting data structure.
209 The two are subtly different in case of data structures that contain
211 references to the root element. In that case, the return value will be
212 a (non-recursive) copy of the reference. The pass-in style is more
213 correct. In other words,
214 $decoder->decode($sereal_string, my $out);
216 # is almost the same but safer than:
217 my $out = $decoder->decode($sereal_string);
218 This is an unfortunate side-effect of perls standard copy semantics of
220 assignment. Possibly one day we will have an alternative to this.
221 decode_with_header
223 Given a byte string of Sereal data, the "decode_with_header" call
224 deserializes that data structure as "decode" would do, however it also
225 decodes the optional user data structure that can be embedded into a
226 Sereal document, inside the header (see Sereal::Encoder::encode).
227 It accepts an optional second parameter, which is a scalar to write the
229 body to, and an optional third parameter, which is a scalar to write
230 the header to.
231 Regardless of the number of parameters received, "decode_with_header"
233 returns an ArrayRef containing the deserialized header, and the
234 deserialized body, in this order.
235 See "decode" for the subtle difference between the one, two and three
237 parameters versions.
238 If there is no header in a Sereal document, corresponding variable or
240 return value will be set to undef.
241 decode_only_header
243 Given a byte string of Sereal data, the "decode_only_header"
244 deserializes only the optional user data structure that can be embedded
245 into a Sereal document, inside the header (see
246 Sereal::Encoder::encode).
247 It accepts an optional second parameter, which is a scalar to write the
249 header to.
250 Regardless of the number of parameters received, "decode_only_header"
252 returns the resulting data structure.
253 See "decode" for the subtle difference between the one and two
255 parameters versions.
256 If there is no header in a Sereal document, corresponding variable or
258 return value will be set to undef.
259 decode_with_offset
261 Same as the "decode" method, except as second parameter, you must pass
262 an integer offset into the input string, at which the decoding is to
263 start. The optional "pass-in" style scalar (see "decode" above) is
264 relegated to being the third parameter.
265 decode_only_header_with_offset
267 Same as the "decode_only_header" method, except as second parameter,
268 you must pass an integer offset into the input string, at which the
269 decoding is to start. The optional "pass-in" style scalar (see
270 "decode_only_header" above) is relegated to being the third parameter.
271 decode_with_header_and_offset
273 Same as the "decode_with_header" method, except as second parameter,
274 you must pass an integer offset into the input string, at which the
275 decoding is to start. The optional "pass-in" style scalars (see
276 "decode_with_header" above) are relegated to being the third and fourth
277 parameters.
278 bytes_consumed
280 After using the various "decode" methods documented previously,
281 "bytes_consumed" can return the number of bytes from the body of the
282 input string that were actually consumed by the decoder. That is, if
283 you append random garbage to a valid Sereal document, "decode" will
284 happily decode the data and ignore the garbage. If that is an error in
285 your use case, you can use "bytes_consumed" to catch it.
286 my $out = $decoder->decode($sereal_string);
288 if (length($sereal_string) != $decoder->bytes_consumed) {
289 die "Not all input data was consumed!";
290 }
291 Chances are that if you do this, you're violating UNIX philosophy in
293 "be strict in what you emit but lenient in what you accept".
294 You can also use this to deserialize a list of Sereal documents that is
296 concatenated into the same string (code not very robust...):
297 my @out;
299 my $pos = 0;
300 eval {
301 while (1) {
302 push @out, $decoder->decode_with_offset($sereal_string, $pos);
303 $pos += $decoder->bytes_consumed;
304 last if $pos >= length($sereal_string)
305 or not $decoder->bytes_consumed;
306 }
307 };
308 As mentioned, only the bytes consumed from the body are considered. So
310 the following example is correct, as only the header is deserialized:
311 my $header = $decoder->decode_only_header($sereal_string);
313 my $count = $decoder->bytes_consumed;
314 # $count is 0
315 decode_from_file
317 Sereal::Decoder->decode_from_file($file);
318 $decoder->decode_from_file($file);
319 Read and decode the file specified. If called in list context and
321 incremental mode is enabled then decodes all packets contained in the
322 file and returns a list, otherwise decodes the first (or only) packet
323 in the file. Accepts an optinal "target" variable as a second argument.
324 looks_like_sereal
326 Performs some rudimentary check to determine if the argument appears to
327 be a valid Sereal packet or not. These tests are not comprehensive and
328 a true result does not mean that the document is valid, merely that it
329 appears to be valid. On the other hand a false result is always
330 reliable.
331 The return of this method may be treated as a simple boolean but is in
333 fact a more complex return. When the argument does not look anything
334 like a Sereal document then the return is perl's FALSE, which has the
335 property of being string equivalent to "" and numerically equivalent to
336 0. However when the argument appears to be a UTF-8 encoded protocol 3
337 Sereal document (by noticing that the \xF3 in the magic string has been
338 replaced by \xC3\xB3) then it returns 0 (the number, which is string
339 equivalent to "0"), and otherwise returns the protocol version of the
340 document. This means you can write something like this:
341 $type= Sereal::Decoder->looks_like_sereal($thing);
343 if ($type eq '') {
344 say "Not a Sereal document";
345 } elsif ($type eq '0') {
346 say "Possibly utf8 encoded Sereal document";
347 } else {
348 say "Sereal document version $type";
349 }
350 For reference, Sereal's magic value is a four byte string which is
352 either "=srl" for protocol version 1 and 2 or "=\xF3rl" for protocol
353 version 3 and later. This function checks that the magic string
354 corresponds with the reported version number, as well as other checks,
355 which may be enhanced in the future.
356 Note that looks_like_sereal() may be called as a class or object
358 method, and may also be called as a single argument function. See the
359 related scalar_looks_like_sereal() for a version which may ONLY be
360 called as a function, not as a method (and which is typically much
361 faster).
362
364 sereal_decode_with_object
365 The functional interface that is equivalent to using "decode". Takes a
366 decoder object reference as first parameter, followed by a byte string
367 to deserialize. Optionally takes a third parameter, which is the
368 output scalar to write to. See the documentation for "decode" above for
369 details.
370 This functional interface is marginally faster than the OO interface
372 since it avoids method resolution overhead and, on sufficiently modern
373 Perl versions, can usually avoid subroutine call overhead. See
374 Sereal::Performance for a discussion on how to tune Sereal for maximum
375 performance if you need to.
376 sereal_decode_with_header_with_object
378 The functional interface that is equivalent to using
379 "decode_with_header". Takes a decoder object reference as first
380 parameter, followed by a byte string to deserialize. Optionally takes
381 third and fourth parameters, which are the output scalars to write to.
382 See the documentation for "decode_with_header" above for details.
383 This functional interface is marginally faster than the OO interface
385 since it avoids method resolution overhead and, on sufficiently modern
386 Perl versions, can usually avoid subroutine call overhead. See
387 Sereal::Performance for a discussion on how to tune Sereal for maximum
388 performance if you need to.
389 sereal_decode_only_header_with_object
391 The functional interface that is equivalent to using
392 "decode_only_header". Takes a decoder object reference as first
393 parameter, followed by a byte string to deserialize. Optionally takes a
394 third parameters, which outputs scalars to write to. See the
395 documentation for "decode_with_header" above for details.
396 This functional interface is marginally faster than the OO interface
398 since it avoids method resolution overhead and, on sufficiently modern
399 Perl versions, can usually avoid subroutine call overhead. See
400 Sereal::Performance for a discussion on how to tune Sereal for maximum
401 performance if you need to.
402 sereal_decode_only_header_with_offset_with_object
404 The functional interface that is equivalent to using
405 "decode_only_header_with_offset". Same as the
406 "sereal_decode_only_header_with_object" function, except as the third
407 parameter, you must pass an integer offset into the input string, at
408 which the decoding is to start. The optional "pass-in" style scalar
409 (see "sereal_decode_only_header_with_object" above) is relegated to
410 being the fourth parameter.
411 This functional interface is marginally faster than the OO interface
413 since it avoids method resolution overhead and, on sufficiently modern
414 Perl versions, can usually avoid subroutine call overhead. See
415 Sereal::Performance for a discussion on how to tune Sereal for maximum
416 performance if you need to.
417 sereal_decode_with_header_and_offset_with_object
419 The functional interface that is equivalent to using
420 "decode_with_header_and_offset". Same as the
421 "sereal_decode_with_header_with_object" function, except as the third
422 parameter, you must pass an integer offset into the input string, at
423 which the decoding is to start. The optional "pass-in" style scalars
424 (see "sereal_decode_with_header_with_object" above) are relegated to
425 being the fourth and fifth parameters.
426 This functional interface is marginally faster than the OO interface
428 since it avoids method resolution overhead and, on sufficiently modern
429 Perl versions, can usually avoid subroutine call overhead. See
430 Sereal::Performance for a discussion on how to tune Sereal for maximum
431 performance if you need to.
432 sereal_decode_with_offset_with_object
434 The functional interface that is equivalent to using
435 "decode_with_offset". Same as the "sereal_decode_with_object"
436 function, except as the third parameter, you must pass an integer
437 offset into the input string, at which the decoding is to start. The
438 optional "pass-in" style scalar (see "sereal_decode_with_object" above)
439 is relegated to being the third parameter.
440 This functional interface is marginally faster than the OO interface
442 since it avoids method resolution overhead and, on sufficiently modern
443 Perl versions, can usually avoid subroutine call overhead. See
444 Sereal::Performance for a discussion on how to tune Sereal for maximum
445 performance if you need to.
446 decode_sereal
448 The functional interface that is equivalent to using "new" and
449 "decode". Expects a byte string to deserialize as first argument,
450 optionally followed by a hash reference of options (see documentation
451 for new()). Finally, "decode_sereal" supports a third parameter, which
452 is the output scalar to write to. See the documentation for "decode"
453 above for details.
454 This functional interface is significantly slower than the OO interface
456 since it cannot reuse the decoder object.
457 decode_sereal_with_header_data
459 The functional interface that is equivalent to using "new" and
460 "decode_with_header". Expects a byte string to deserialize as first
461 argument, optionally followed by a hash reference of options (see
462 documentation for new()). Finally, "decode_sereal" supports third and
463 fourth parameters, which are the output scalars to write to. See the
464 documentation for "decode_with_header" above for details.
465 This functional interface is significantly slower than the OO interface
467 since it cannot reuse the decoder object.
468 scalar_looks_like_sereal
470 The functional interface that is equivalent to using
471 "looks_like_sereal".
472 Note that this version cannot be called as a method. It is normally
474 executed as a custom opcode, as such errors about its usage may be
475 caught at compile time, and it should be much faster than
476 looks_like_sereal.
477
479 This implementation of a Sereal decoder tries to be as robust to
480 invalid input data as reasonably possible. This means that it should
481 never (though read on) segfault. It may, however, cause a large malloc
482 to fail. Generally speaking, invalid data should cause a Perl-trappable
483 exception. The one exception is that for Snappy-compressed Sereal
484 documents, the Snappy library may cause segmentation faults (invalid
485 reads or writes). This should only be a problem if you do not checksum
486 your data (internal checksum support is a To-Do) or if you accept data
487 from potentially malicious sources.
488 It requires a lot of run-time boundary checks to prevent decoder
490 segmentation faults on invalid data. We implemented them in the
491 lightest way possible. Adding robustness against running out of memory
492 would cause an very significant run-time overhead. In most cases of
493 random garbage (with valid header no less) when a malloc() fails due to
494 invalid data, the problem was caused by a very large array or string
495 length. This kind of very large malloc can then fail, being trappable
496 from Perl. Only when packet causes many repeated allocations do you
497 risk causing a hard OOM error from the kernel that cannot be trapped
498 because Perl may require some small allocations to succeed before the
499 now-invalid memory is released. It is at least not entirely trivial to
500 craft a Sereal document that causes this behaviour.
501 Finally, deserializing proper objects is potentially a problem because
503 classes can define a destructor. Thus, the data fed to the decoder can
504 cause the (deferred) execution of any destructor in your application.
505 That's why the "refuse_objects" option exists and what the
506 "no_bless_objects" can be used for as well. Later on, we may or may not
507 provide a facility to whitelist classes. Furthermore, if the encoder
508 emitted any objects using "FREEZE" callbacks, the "THAW" class method
509 may be invoked on the respective classes. If you can't trust the source
510 of your Sereal documents, you may want to use the "refuse_objects"
511 option. For more details on the "FREEZE/THAW" mechanism, please refer
512 to Sereal::Encoder.
513
515 Some objects do not lend themselves naturally to naive perl
516 datastructure level serialization. For instance XS code might use a
517 hidden structure that would not get serialized, or an object may
518 contain volatile data like a filehandle that would not be reconstituted
519 properly. To support cases like this "Sereal" supports a FREEZE and
520 THAW api. When objects are serialized their FREEZE method is asked for
521 a replacement representation, and when objects are deserialized their
522 THAW method is asked to convert that replacement back to something
523 useful.
524 For security reasons decoding an object will NOT autoload any modules
526 to support THAW, however if the classes and methods are preloaded it
527 will invoke THAW as required and an exception will be thrown if the
528 class has not been loaded. It is possible to disable THAW in the
529 decoder by using the "no_thaw_objects" option, which when true causes
530 frozen objects to be blessed into a special utility class
531 "Sereal::Decoder::THAW_args" for debugging. The objects themselves are
532 an array, whose last member will contain the class name the arguments
533 are for.
534 Prior to v4.024 the decoder had issues with frozen representations that
536 contained other objects and did not define a specific order that items
537 would be thawed and blessed, making it impractical to put an object
538 inside of the frozen representation of another object.
539 As of v4.024 frozen representations may contain other objects, and the
541 order in which they are thawed is defined to be LIFO, thus the
542 arguments to a THAW method will themselves be thawed (if need be)
543 before the call to the containing objects THAW method. Thawing occurs
544 only after all simple objects have been blessed into their appropriate
545 object form.
546 The FREEZE/THAW mechanism is inspired by the equivalent mechanism in
548 CBOR::XS. The general mechanism is documented in the A GENERIC OBJECT
549 SERIALIATION PROTOCOL section of Types::Serialiser. Similar to CBOR
550 using "CBOR", Sereal uses the string "Sereal" as a serializer
551 identifier for the callbacks.
552
554 Please refer to the Sereal::Performance document that has more detailed
555 information about Sereal performance and tuning thereof.
556
558 "Sereal::Decoder" is thread-safe on Perl's 5.8.7 and higher. This means
559 "thread-safe" in the sense that if you create a new thread, all
560 "Sereal::Decoder" objects will become a reference to undef in the new
561 thread. This might change in a future release to become a full clone of
562 the decoder object.
563
565 For reporting bugs, please use the github bug tracker at
566 <http://github.com/Sereal/Sereal/issues>.
567 For support and discussion of Sereal, there are two Google Groups:
569 Announcements around Sereal (extremely low volume):
571 <https://groups.google.com/forum/?fromgroups#!forum/sereal-announce>
572 Sereal development list:
574 <https://groups.google.com/forum/?fromgroups#!forum/sereal-dev>
575
577 Yves Orton <demerphq@gmail.com>
578 Damian Gryski
580 Steffen Mueller <smueller@cpan.org>
582 Rafaël Garcia-Suarez
584 Ævar Arnfjörð Bjarmason <avar@cpan.org>
586 Tim Bunce
588 Daniel Dragan <bulkdd@cpan.org> (Windows support and bugfixes)
590 Zefram
592 Borislav Nikolov
594 Ivan Kruglov <ivan.kruglov@yahoo.com>
596 Eric Herman <eric@freesa.org>
598 Some inspiration and code was taken from Marc Lehmann's excellent
600 JSON::XS module due to obvious overlap in problem domain.
601
603 This module was originally developed for Booking.com. With approval
604 from Booking.com, this module was generalized and published on CPAN,
605 for which the authors would like to express their gratitude.
606
608 Copyright (C) 2012, 2013, 2014 by Steffen Mueller Copyright (C) 2012,
609 2013, 2014 by Yves Orton
610 The license for the code in this distribution is the following, with
612 the exceptions listed below:
613 This library is free software; you can redistribute it and/or modify it
615 under the same terms as Perl itself.
616 Except portions taken from Marc Lehmann's code for the JSON::XS module,
618 which is licensed under the same terms as this module. (Many thanks to
619 Marc for inspiration, and code.)
620 Also except the code for Snappy compression library, whose license is
622 reproduced below and which, to the best of our knowledge, is compatible
623 with this module's license. The license for the enclosed Snappy code
624 is:
625 Copyright 2011, Google Inc.
627 All rights reserved.
628 Redistribution and use in source and binary forms, with or without
630 modification, are permitted provided that the following conditions are
631 met:
632 * Redistributions of source code must retain the above copyright
634 notice, this list of conditions and the following disclaimer.
635 * Redistributions in binary form must reproduce the above
636 copyright notice, this list of conditions and the following disclaimer
637 in the documentation and/or other materials provided with the
638 distribution.
639 * Neither the name of Google Inc. nor the names of its
640 contributors may be used to endorse or promote products derived from
641 this software without specific prior written permission.
642 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
644 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
645 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
646 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
647 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
648 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
649 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
650 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
651 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
652 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
653 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
654perl v5.36.0 2023-02-08 Sereal::Decoder(3)