On Tue, Apr 23, 2024 at 10:19:47PM +0100, Stuart Henderson wrote: > On 2024/04/01 12:55, Kirill A. Korinsky wrote: > > Folks, > > > > Despite of current security issue with xz/lzma the algortihm itself provides > > great compression, and the existing XZ Utils provide great compression in > > the .xz file format, but they produce just one big block of compressed data. > > > > Here, a new port which is called archivers/pixz which produces a collection > > of smaller blocks which makes random access to the original data possible. > > This is especially useful for large tarballs. > > > > This can be used as seprated application or via tar, that described on > > homepage: https://github.com/vasi/pixz > > > > -- > > wbr, Kirill > > Small tweaks, mostly to fix things so the tests run properly (symlink > gstat -> WRKDIR/bin/stat, and BDEP on cppcheck). The cppcheck still > fails but due to a detected error rather than because it can't run. > > ----- > Checking ../src/write.c ... > ../src/write.c:460:24: error: Uninitialized variable: obuf [uninitvar] > if (fwrite(obuf, CHUNKSIZE - gStream.avail_out, 1, gOutFile) != 1) > ^ > ../src/write.c:527:24: error: Uninitialized variable: obuf [uninitvar] > if (fwrite(obuf, CHUNKSIZE - gStream.avail_out, 1, gOutFile) != 1) > ^ > ----- > > Looking at the code it seems cppcheck is probably right? >
Smells like a false positive to me. In both cases there's 'gStream.next_out = obuf' and lzma_code(&gstream, ...) This means obuf is the gStream's output buffer and these fwrite are only reached if lzma_code() actually has written something to next_out, the number of bytes being CHUNKSIZE - gStream.avail_out, so these two calls look right to me. After writing this, I see Kirill's mail that this was 'fixed' upstream. Fine The port needs LDEPS on archivers/libarchive and archivers/xz and WANTLIB += archive lzma With this, ok tb
