From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Adam Richter Newsgroups: gmane.emacs.devel Subject: [Low priority] Some minor complaints from cppcheck about emacs 26.2 Date: Tue, 30 Apr 2019 14:38:16 -0700 Message-ID: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="000000000000a920e40587c638d4" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="55017"; mail-complaints-to="usenet@blaine.gmane.org" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 30 23:39:08 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hLaSx-000E9u-JL for ged-emacs-devel@m.gmane.org; Tue, 30 Apr 2019 23:39:07 +0200 Original-Received: from localhost ([127.0.0.1]:53908 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLaSw-00023H-L0 for ged-emacs-devel@m.gmane.org; Tue, 30 Apr 2019 17:39:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38606) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLaSO-000236-0P for emacs-devel@gnu.org; Tue, 30 Apr 2019 17:38:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hLaSM-0007dF-SB for emacs-devel@gnu.org; Tue, 30 Apr 2019 17:38:31 -0400 Original-Received: from mail-ua1-x941.google.com ([2607:f8b0:4864:20::941]:36793) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hLaSM-0007cr-KG for emacs-devel@gnu.org; Tue, 30 Apr 2019 17:38:30 -0400 Original-Received: by mail-ua1-x941.google.com with SMTP id z17so922970uar.3 for ; Tue, 30 Apr 2019 14:38:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=bUDAZ+T+lfcUkFS+yUTUKXkoPRa7Aq78HUuL/cKJCXw=; b=HM9+5uG+zXGqgNnvYrq3vZqyGkXv3Kw4AJvaDu8rMbF/aawo+vfnbw+LEGDLKAZlhx o5VEIqGYgdZ52lHYw8vdRffx9BniUDmZQXkidYO4tQKuYkYuzCJ5QKOTqNm1J8I+xNmQ pkRYqSPoa/ufKogIERaguE+aqL7VucxwgD8QCSt2Q09DWUHTUZlwxTxj50w2MFUUl7QR iauvixYpLsIxXcfsLlXfwjTWk9FHBms8gQC0eU4BlzDDUBY486Y7rPhHhCE/DetwY0rS 4jShPPEgvaEjP2s1T/PqKaeCQSWmF3EzfCa3KPG7JYtDxkIZNCkKSmHcIPb44J0Moc3B 1rFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bUDAZ+T+lfcUkFS+yUTUKXkoPRa7Aq78HUuL/cKJCXw=; b=s09L4YjT140GM5MGCthcgQNIYQd+I+mZ9abQdpEZpigBIfdAOOHofyjUvV70J9OXAo 3OUowO7ISvlvS4L/jLP/rV4Zlre1aS+fWFSK1HwwyYWdIL/CxVAYgPs9aueDmoJICDnD EEUslVvqxHsD2GLVWYzTNb0PHwSdjAJnNRYBlma8eAWL4Mb/jpnAR3oswzXn5uBSeGNi QCQZTQHTAKT6di63akk+mL8pQq85h5oS0qRt0hCjmozq28hbyDaFGtJSgyYvK0eGuxrQ 8/vtaxMYSpRtfK3x03GJh2xttHbxSVI2GPSyh6aiLiOxTwLEC6sy7oj++6wAcg/DsOaI LH/Q== X-Gm-Message-State: APjAAAVQBxr7kukmusoVWEAM93YemY0VSjCR+Y68W7Kv30ATYinG+iTA /ZVB6bppvoGxTedADP/5VcGDjEivEBwaxLWsoqSENGu/ X-Google-Smtp-Source: APXvYqxCSgw+9440jW9a0JI86rTUNjpS0TrfgJFQZggWOXIwPLDepQ2dS6xtdlp3n5lpjyCAQ9Rb7HtKr41OG5InTlo= X-Received: by 2002:ab0:2b19:: with SMTP id e25mr2940835uar.68.1556660307423; Tue, 30 Apr 2019 14:38:27 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::941 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236076 Archived-At: --000000000000a920e40587c638d4 Content-Type: text/plain; charset="UTF-8" Hi, everyone. I just tried running the version of cppcheck from the github repository (which fixes at least one false positive report that I have been seeing from cppcheck 1.86) on emacs 26.2 sources, and cppcheck appears to have a found a few bugs that probably don't cause external misbehavior, but I'm not sure are completely safe. So, I am sending this message with the cppcheck output attached, in the hopes that by saving emacs developers the time of building the latest cppcheck and doing a superficial check of the warnings, one or more people on the list might find it worth taking a glance that the messages that I could not rule out as completely spurious, and also in the hopes of saving time for anyone else who runs cppcheck on emacs and sees the same warnings. Here is a list of files listed in the attached cppcheck and my notes about them. lib-src/ebrowse.c <-- Not a bug. strdup is supposed to "leak" a malloc. lib-src/update-game-score.c <-- I submitted a patch attached to a message to this mailing list a few minutes ago, which I think fixes the legitimate complaints. The last complaint ("realloc mistake") does not appear to be a bug. lib/stdint.h <-- This is a real typographical bug and I don't know what the author intended. lib/nstrftime.c <-- Possibly a real bug, but only if multibyte is disabled. A local variable "width", set to -1, is used by a macro that I think may expect a positive value, but I am not sure of this fix. nt/preprep.c <-- These are complaints about copy_executable_and_move_sections() where the variable import_delta_rva might not be set if import_section == NULL and rva_to_section() also returns NULL. I am not sure if this really can happen and if the resultant undefined value is consequential in that case. src/regex.c <--I think the tiny memory leak for compile_stack.stack is real. Everything else is probably not a legitimate complaint, although I'm not 100% sure about that. I think the "Uninitialized variable" complaints about len and buf_charlen are all wrong, possibly due to cppcheck trying all combinations of #ifdef's and perhaps finding one that does not define the macros that set these variables. src/regex.h <-- This complaint seems completely spurious (use of #ifdef in the middle of a function declaration). lib-src/etags.c <-- I believe that this complaint about a possible null pointer dereference is spurious because filename_is_absolute() would need to return true in one place and false in another with the same data in order for that to happen. Anyhow, if anyone has any questions, please feel free to ask me or discuss on this list, as you think appropriate. I hope this information is helpful. Adam --000000000000a920e40587c638d4 Content-Type: application/octet-stream; name="emacs-26.2.cppcheck.log" Content-Disposition: attachment; filename="emacs-26.2.cppcheck.log" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jv4asnfl0 W2xpYi1zcmMvZWJyb3dzZS5jOjUzMl06IChlcnJvcikgQWxsb2NhdGlvbiB3aXRoIHhtYWxsb2Ms IHN0cmNweSBkb2Vzbid0IHJlbGVhc2UgaXQuCltsaWItc3JjL3VwZGF0ZS1nYW1lLXNjb3JlLmM6 MzI5XTogKGVycm9yKSBNZW1vcnkgbGVhazogZmlsZWRhdGEKW2xpYi1zcmMvdXBkYXRlLWdhbWUt c2NvcmUuYzozMzRdOiAoZXJyb3IpIE1lbW9yeSBsZWFrOiBmaWxlZGF0YQpbbGliLXNyYy91cGRh dGUtZ2FtZS1zY29yZS5jOjMzOV06IChlcnJvcikgTWVtb3J5IGxlYWs6IGZpbGVkYXRhCltsaWIt c3JjL3VwZGF0ZS1nYW1lLXNjb3JlLmM6NDEwXTogKGVycm9yKSBDb21tb24gcmVhbGxvYyBtaXN0 YWtlOiAnbmV3c2NvcmVzJyBudWxsZWQgYnV0IG5vdCBmcmVlZCB1cG9uIGZhaWx1cmUKW2xpYi9z dGRpbnQuaDo1MzddOiAoZXJyb3IpIFN5bnRheCBlcnJvciBpbiAjaWYKW2xpYi9uc3RyZnRpbWUu Yzo2NjBdOiAoZXJyb3IpIEludmFsaWQgbWVtc2V0KCkgYXJndW1lbnQgbnIgMy4gVGhlIHZhbHVl IGlzIC0yIGJ1dCB0aGUgdmFsaWQgdmFsdWVzIGFyZSAnMDonLgpbbGliL25zdHJmdGltZS5jOjY2 MF06IChlcnJvcikgSW52YWxpZCB3bWVtc2V0KCkgYXJndW1lbnQgbnIgMy4gVGhlIHZhbHVlIGlz IC0yIGJ1dCB0aGUgdmFsaWQgdmFsdWVzIGFyZSAnMDonLgpbbnQvcHJlcHJlcC5jOjU3MF06IChl cnJvcikgVW5pbml0aWFsaXplZCB2YXJpYWJsZTogaW1wb3J0X2RlbHRhX3J2YQpbbnQvcHJlcHJl cC5jOjU5N106IChlcnJvcikgVW5pbml0aWFsaXplZCB2YXJpYWJsZTogaW1wb3J0X2RlbHRhX3J2 YQpbbnQvcHJlcHJlcC5jOjY2M106IChlcnJvcikgVW5pbml0aWFsaXplZCB2YXJpYWJsZTogZW5k X2Jsb2NrCltudC9wcmVwcmVwLmM6NjY5XTogKGVycm9yKSBVbmluaXRpYWxpemVkIHZhcmlhYmxl OiBlbmRfYmxvY2sKW3NyYy9yZWdleC5jOjI1NjNdOiAoZXJyb3IpIE1lbW9yeSBsZWFrOiBjb21w aWxlX3N0YWNrLnN0YWNrCltzcmMvcmVnZXguYzo1MDg1XTogKGVycm9yKSBQb2ludGVyIGFkZGl0 aW9uIHdpdGggTlVMTCBwb2ludGVyLgpbc3JjL3JlZ2V4LmM6MjU2M106IChlcnJvcikgVW5pbml0 aWFsaXplZCB2YXJpYWJsZTogbGVuCltzcmMvcmVnZXguYzoyNjgxXTogKGVycm9yKSBVbmluaXRp YWxpemVkIHZhcmlhYmxlOiBsZW4KW3NyYy9yZWdleC5jOjI2ODhdOiAoZXJyb3IpIFVuaW5pdGlh bGl6ZWQgdmFyaWFibGU6IGxlbgpbc3JjL3JlZ2V4LmM6Mjg5N106IChlcnJvcikgVW5pbml0aWFs aXplZCB2YXJpYWJsZTogbGVuCltzcmMvcmVnZXguYzoyOTA0XTogKGVycm9yKSBVbmluaXRpYWxp emVkIHZhcmlhYmxlOiBsZW4KW3NyYy9yZWdleC5jOjI5MjBdOiAoZXJyb3IpIFVuaW5pdGlhbGl6 ZWQgdmFyaWFibGU6IGxlbgpbc3JjL3JlZ2V4LmM6MjkyM106IChlcnJvcikgVW5pbml0aWFsaXpl ZCB2YXJpYWJsZTogbGVuCltzcmMvcmVnZXguYzozMDU5XTogKGVycm9yKSBVbmluaXRpYWxpemVk IHZhcmlhYmxlOiBsZW4KW3NyYy9yZWdleC5jOjMwNzZdOiAoZXJyb3IpIFVuaW5pdGlhbGl6ZWQg dmFyaWFibGU6IGxlbgpbc3JjL3JlZ2V4LmM6MzA3OV06IChlcnJvcikgVW5pbml0aWFsaXplZCB2 YXJpYWJsZTogbGVuCltzcmMvcmVnZXguYzozMjcwXTogKGVycm9yKSBVbmluaXRpYWxpemVkIHZh cmlhYmxlOiBsZW4KW3NyYy9yZWdleC5jOjMyNzNdOiAoZXJyb3IpIFVuaW5pdGlhbGl6ZWQgdmFy aWFibGU6IGxlbgpbc3JjL3JlZ2V4LmM6MzI4OF06IChlcnJvcikgVW5pbml0aWFsaXplZCB2YXJp YWJsZTogbGVuCltzcmMvcmVnZXguYzozNDg4XTogKGVycm9yKSBVbmluaXRpYWxpemVkIHZhcmlh YmxlOiBsZW4KW3NyYy9yZWdleC5jOjQzMjddOiAoZXJyb3IpIFVuaW5pdGlhbGl6ZWQgdmFyaWFi bGU6IGJ1Zl9jaGFybGVuCltzcmMvcmVnZXguYzo0MzI4XTogKGVycm9yKSBVbmluaXRpYWxpemVk IHZhcmlhYmxlOiBidWZfY2hhcmxlbgpbc3JjL3JlZ2V4LmM6NDM1N106IChlcnJvcikgVW5pbml0 aWFsaXplZCB2YXJpYWJsZTogYnVmX2NoYXJsZW4KW3NyYy9yZWdleC5jOjQzNThdOiAoZXJyb3Ip IFVuaW5pdGlhbGl6ZWQgdmFyaWFibGU6IGJ1Zl9jaGFybGVuCltzcmMvcmVnZXguYzo1NDQ1XTog KGVycm9yKSBVbmluaXRpYWxpemVkIHZhcmlhYmxlOiBidWZfY2hhcmxlbgpbc3JjL3JlZ2V4LmM6 NTQ5OF06IChlcnJvcikgVW5pbml0aWFsaXplZCB2YXJpYWJsZTogbGVuCltzcmMvcmVnZXguaDo0 ODVdOiAoZXJyb3IpIGZhaWxlZCB0byBleHBhbmQgJ3JlX2NvbXBpbGVfcGF0dGVybicsIGl0IGlz IGludmFsaWQgdG8gdXNlIGEgcHJlcHJvY2Vzc29yIGRpcmVjdGl2ZSBhcyBtYWNybyBwYXJhbWV0 ZXIKW2xpYi1zcmMvZXRhZ3MuYzoxNzA4XSAtPiBbbGliLXNyYy9ldGFncy5jOjcxNjJdIC0+IFts aWItc3JjL2V0YWdzLmM6NzAyN106IChlcnJvcikgTnVsbCBwb2ludGVyIGRlcmVmZXJlbmNlOiBz MQoKcmVhbAkzbTQ2LjY0MHMKdXNlcgkzbTQ1LjY0MHMKc3lzCTBtMC41NTJzCg== --000000000000a920e40587c638d4--