similar to: [PATCH] Fix cppcheck warnings

I'm looking at an issue reported by the Coverity static analyzer. In iconvert() in src/share/utf8/iconvert.c on line 152 there is newbuf = safe_realloc_add_2op_(utfbuf, ...); If the request size is not valid, the function will free utfbuf and return 0. This is followed by goto fail and utfbuf is freed for the second time. A simply fix would be to set utfbuf to 0 if newbuf is 0. However, this

fedora comes with 1.75 so I used that. I also used some additional flags: cppcheck --enable=all --inconclusive --std=posix --force On Wed, Jan 18, 2017 at 11:36 PM, Erik de Castro Lopo <mle+la at mega-nerd.com> wrote: > Rosen Penev wrote: > >> src/libFLAC/bitreader.c | 4 ++-- >> src/libFLAC/bitwriter.c | 4 ++-- >> src/plugin_xmms/plugin.c |

Hi Chris, et. al, I''ve recently come across cppcheck (static analyser for C code) and ran it on the current btrfs directory from Linus''s repo and it''s reported the following potential issues: linux-2.6$ cppcheck -q fs/btrfs/ [fs/btrfs/compression.c:343]: (error) Data is allocated but not initialized: cb [fs/btrfs/compression.c:583]: (error) Data is allocated but not

Hello there, I just ran the sourceforge tool cppcheck over the source code of the new Linux kernel 2.6.32.4 It said 1. [./btrfs/free-space-cache.c:600]: (style) Redundant condition. It is safe to deallocate a NULL pointer The source code is                 if (info->bitmap)                         kfree(info->bitmap); I agree with cppcheck. Suggest delete the if test. 2.

Hi All, I think there is a memory error in the libcurl connection code that typically happens when libcurl reads big chunks of data. This potentially affects all code that use url() with the libcurl download method, which is the default in most builds. In practice it tends to happen more with HTTP/2 and if the connection is wrapped into a gzcon(). macOS Catalina has a libcurl build with HTTP/2

I've been playing around with snapshots lately but I've got a problem on one of my servers running 7-STABLE amd64: FreeBSD paladin 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #8: Mon Nov 10 20:49:51 GMT 2008 tdb@paladin:/usr/obj/usr/src/sys/PALADIN amd64 I run the mksnap_ffs command to take the snapshot and some time later the system completely freezes up: paladin# cd /u2/.snap/ paladin#

Hi, A system running ext3 crashed this afternoon (nothing to do with ext3, bad network driver). Is was saving a file from emacs when it happened. The file system is 0.06b and had ordered data as the mount option. Let me emphasize this was running ext3 pure, not with SnapFS or InterMezzo layered on top of it. strace reveals that Emacs does open("existing file name", O_TRUNC |

I'm using libFLACC++ and libFLAC and I think that I'm using the calls in the typical order (see code below). But every monoe or stereo file that I send thru I get files that are the same sze as the orginal wave files. Doing a flac -a on the flac files I see that I get: frame=9 blocksize=4608 sample_rate=8000 channels=1 channel_assignment=INDEPENDENT subframe=0

O.K. I know it was too late to make changes for the next release, but thankfully there werent any changes needed. Kerberos over ssh protocol 1 worked out of the box from CVS today (2002/10/04-14:30) The krb5 patches we were using (I think from Olaf K) was all in the code. The only thing I had to patch to get things working was removing the scard-install from the Makefile.in The compiled code

looks fine, I would suspect how the PCM sample are formatted and sent to process(), could you show that part of the code? Josh --- James Smith <jsmith@landmarkdigital.com> wrote: > > I'm using libFLACC++ and libFLAC and I think that I'm using the calls > in the > typical order (see code below). But every monoe or stereo file that > I send > thru I get files

Hello all, The itanium demangler in libcxxabi (and also, llvm/lib/Demangle) is really slow. This is largely because the textual representation of the symbol that is being demangled is held in a std::string, and manipulations done during parsing are done on that string. The demangler is always concatenating strings and inserting into the middle of strings, which is terrible. The fact that the

Here's how I set up the data for processing: // For moving data into 32 bit shape uint8_t *buffer8 = NULL; uint16_t *buffer16 = NULL; uint32_t *buffer32 = NULL; unsigned sample32; unsigned sample, channel; uint32_t bitsPerSample = this->get_bits_per_sample(); numFrames = inData.GetSize();