Age | Commit message (Collapse) | Author |
|
* essen/zlib-windowbits:
Update zlib:zwindowbits/0 type to accept 8 and -8
OTP-12564
|
|
Commit 7e8f5a776cbfa376e03369d058a90c8dd9f217fc (importing R11B-3)
updated zlib, which had changed what values it accepts for window
bits from 9-15 to 8-15.
From deflate.c:
- windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
- strategy < 0 || strategy > Z_HUFFMAN_ONLY) {
+ windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
+ strategy < 0 || strategy > Z_FIXED) {
return Z_STREAM_ERROR;
}
+ if (windowBits == 8) windowBits = 9; /* until 256-byte window bug fixed */
In inflate.c 8 was already an accepted value.
This commit updates OTP to also accept the values 8 and -8.
|
|
This functionality may be useful for compressed streams with high
compression ratio (in case of gzip it may be up to x1000), when
small amount of compressed data will produce large amount of
uncompressed output. This may lead to DoS attacks, because
server easily goes out of memory.
Example of such high compression ratio stream:
```
dd if=/dev/zero of=sparse.bin bs=1MB count=100 # 100mb of zeroes
gzip sparse.bin # 95kb sparse.bin.gz
$ erl
> {ok, Compressed} = file:read_file("sparse.bin.gz"),
> 97082 = size(Compressed),
> Uncompressed = zlib:gunzip(Compressed),
> 100000000 = iolist_size(Uncompressed).
```
|
|
|
|
|
|
Commontest doesn't like arity 0 function with same name as test case.
|
|
|
|
zip,unzip,gzip,gunzip,compress and uncompress did not close the port
when given invalid data argument. Fixed by putting close in "try-after".
A closed port could in same cases get stuck in limbo due to data in
io-queue. Fixed by adding a flush callback.
|
|
* dev:
Update documentation and specifications of some of the zlib functions
Conflicts:
erts/preloaded/ebin/zlib.beam
|
|
The functions zlib:deflateSetDictionary/2 and zlib:inflateSetDictionary/2
accept iodata() as Dictionary.
The functions zlib:crc32/2,3, zlib:adler32/2,3, zlib:compress/1,
zlib:uncompress/1, zlib:zip/1, and zlib:unzip/1 accept iodata() as
data.
|
|
This commit is a preparation for introducing location information
(filename/line number) in stacktraces in exceptions. Currently
a stack trace looks like:
[{Mod1,Function1,Arity1},
.
.
.
{ModN,FunctionN,ArityN}]
Add a forth element to each tuple that can be used indication
the filename and line number of the source file:
[{Mod1,Function1,Arity1,Location1},
.
.
.
{ModN,FunctionN,ArityN,LocationN}]
In this commit, the fourth element will just be an empty list,
and we will change all code that look at or manipulate stacktraces.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|