I encounter the error message when running cppcheck 1.84 to harness.c.

$ : cppcheck harness.c
Checking harness.c ...
[harness.c:148]: (error) Address of auto-variable 'new_block->payload' returned

There may be two solutions:

1. amikai's note
2. add printf to print the pointer of p

void *p = (void *) &new_block->payload;
memset(p, FILLCHAR, size);
printf("%p\n", p);  
...
...
...
return p;

Greetings!

Here's a bug in commit e124032

$ git checkout e124032
$ make
$ ./qtest
cmd> quit
Freeing queue
Segmentation fault occurred.  You dereferenced a NULL or invalid pointer
Aborted (core dumped)
$ ./qtest - f traces/trace-quit.cmd
cmd> # test quit
cmd> quit
Freeing queue

The segfault occurred only when without the -f flag.
Here's the valgrind output:

$ valgrind ./qtest
cmd> quit
Freeing queue
==11424== Invalid read of size 4
==11424==    at 0x10E514: run_console (console.c:653)
==11424==    by 0x10C9BB: main (qtest.c:1066)
==11424==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==11424== 
Segmentation fault occurred.  You dereferenced a NULL or invalid pointer
==11424== 5 bytes in 1 blocks are still reachable in loss record 1 of 3
==11424==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11424==    by 0x4A5850E: strdup (strdup.c:42)
==11424==    by 0x1106D8: linenoiseHistoryAdd (linenoise.c:1236)
==11424==    by 0x11126B: linenoiseHistoryLoad (linenoise.c:1325)
==11424==    by 0x10CA16: main (qtest.c:1053)
==11424== 
==11424== 143 bytes in 18 blocks are still reachable in loss record 2 of 3
==11424==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11424==    by 0x4A5850E: strdup (strdup.c:42)
==11424==    by 0x11064C: linenoiseHistoryAdd (linenoise.c:1236)
==11424==    by 0x11126B: linenoiseHistoryLoad (linenoise.c:1325)
==11424==    by 0x10CA16: main (qtest.c:1053)
==11424== 
==11424== 160 bytes in 1 blocks are still reachable in loss record 3 of 3
==11424==    at 0x483B7F3: malloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==11424==    by 0x110698: linenoiseHistoryAdd (linenoise.c:1224)
==11424==    by 0x11126B: linenoiseHistoryLoad (linenoise.c:1325)
==11424==    by 0x10CA16: main (qtest.c:1053)
==11424== 
Aborted (core dumped)

I'm working on it, but still not sure what's going on.

Aspell-en is a "recommend" package in Ubuntu, so it will be installed with aspell package.
But in other distros like Arch, it won't auto install, and terminal will output error by below when I commit:

Error: No word lists can be found for the language "en".

But I can still commit successfully with this error.

So I think that should be added in readme or adding a protect in pre-commit hook.

Summary

When we made some modification to the content and trying to git push the changes to our remote repository, /scripts/pre-push.hook present a stage for validation of the repository.
It tries to get a specific commit hash number with git log message pattern matching "^Bump copyright" using the following command

commit=$(git rev-list -n 1 --grep '^Bump copyright' 1aca5b98471765db50c91e03298e49bf7c08cdbc...HEAD)

The value of commit is expected to be "3ed17237af5b1ead6c394df5099bc2bc1f8392df".
However, since you have another git commit which is "Merge pull request #150 from sysprog21/bump-copyright-year".
Its commit message also matches the pattern of ^Bump copyright, so the command mentioned above for getting the value of commit will make the value of commit result in 390ade9eca44b432acb758084e7122cc2c46e485.
This behavior will cause the pre-hook checking stage to fail.

I am not sure the bug is only for me locally or it's truly a bug needed to be fixed.

Expected

commit should be 3ed17237af5b1ead6c394df5099bc2bc1f8392df

Possible fixup

Change line 15 of pre-push.hook to the following command

commit=$(git rev-list --skip 1 --grep '^Bump copyright' 1aca5b98471765db50c91e03298e49bf7c08cdbc...HEAD)

I found that this simple command sequence may stuck in an infinite loop.

new
new
free

If you want to reproduce the problem, you can use my fork https://github.com/yanjiew1/lab0-c.
I will investigate on this problem later.

In q_sort(), it prefered to use a in-place algorithm to sort the list, so it disallowed the malloc() in some testcases.

But I can still use Variable-length array to bypass this limit, and use a algorithm which space complexity is O(n) to pass all testcases.

Is it a fatal problem?

The implementation of q_quit does not consider free all the queues. Instead, it only frees the current queue.

Environment

• Cppcheck Versions: Discrepancy between Cppcheck 2.7 (Docker, Ubuntu 22.04) and Cppcheck 2.12.0 (Host, Archlinux)
• Operating Systems: Ubuntu 22.04 (Docker) vs. Archlinux (Host)
• Issue Context: Encountered during execution of a git pre-commit hook.

Issue Description

The project encounters differing static analysis results when committing changes, triggered by the git pre-commit hook using cppcheck. The root cause appears to be the version difference between the Cppcheck tool in my Docker environment (version 2.7) and on my host system (version 2.12.0), leading to varying default enabled checking flags.

Encountered Issues

• Different cppcheck warnings and errors are reported due to the version discrepancy.
• These include suggestions for declaring parameters as pointers to const, an error about returning a pointer to a local variable, style recommendations, and a notice on limited value flow analysis.

Proposed Solution

To address this issue and achieve consistent static analysis checks across environments, I have implemented specific changes in the codebase and the static analysis configuration.

Changes Made

1. Code Adjustments: Updated function parameters from char * to const char * where appropriate to align with cppcheck recommendations, enhancing code safety and maintainability.
2. Pre-commit Hook Script Update: Modified the scripts/pre-commit.hook to include new suppressions (returnDanglingLifetime, constParameterCallback, constParameterPointer) and added --check-level=exhaustive to the cppcheck options for a thorough analysis.

Implementation Details

The modifications involve:

• Making parameters const in several functions across report.c and report.h files to prevent unintended modifications.
• Adjusting the pre-commit hook to tailor the cppcheck analysis, reducing false positives and focusing on relevant issues.
• See: 25077667@673f5a1

Expected Outcome

With these changes, we expect to:

• Harmonize static analysis checks across different cppcheck versions, reducing inconsistencies.
• Improve code quality by adhering to best practices recommended by static analysis.
• Streamline the development process by minimizing disruptive and differing analysis outcomes between environments.

Request for Feedback

I've proposed a solution that seems to address the observed issues effectively. However, I welcome any feedback or suggestions for improvement from the community. Specifically:

• Are there better approaches to ensure cppcheck version consistency across environments?
• Feedback on the proposed suppressions and cppcheck configuration adjustments.

Your insights and suggestions will be invaluable in refining this solution and ensuring our static analysis process is as robust and consistent as possible.

Root cause:

Using temp file will mess up clang-format IncludeCategories rules for .h

Description:

In clang-format, IncludeCategories will automatically set the filename.h to the highest priority, which mean it will put it at the first of the include block:

The main header for a source file automatically gets category 0. so that it is generally kept at the beginning of the #includes link

But, our hook using the temp file to compare with the source file, causing this rule not work, hence given a no-fix loop for this situation:

Report by the clang-format

$ clang-format this_is_the_actual_filename.c
#ifdef FOOBAR
#include "this_is_the_actual_filename.h"
#include "xxx.h"
#include "xxx.h"
#include "xxx.h"

 #include <xxx.h>
 #include <xxx.h>

Report by the hook

--- .merge_file_Zzz17X	2019-09-26 21:39:09.606926346 +0800
+++ /tmp/.merge_file_Zzz17X.I2ISWZ	2019-09-26 21:39:09.650259682 +0800
@@ -1,8 +1,8 @@
 #ifdef FOOBAR
-#include "this_is_the_actual_filename.h"
 #include "xxx.h"
 #include "xxx.h"
 #include "xxx.h"
+#include "this_is_the_actual_filename.h"
 
 #include <xxx.h>
 #include <xxx.h>

Current qtest shows the help messages in inconsistent manner:

cmd> help
Commands:
  #	 ...            | Display comment
  dedup	                | Delete all nodes that have duplicate string
  descend	                | Remove every node which has a node with a strictly greater value anywhere to the right side of it
  dm	                | Delete middle node in queue

To resolve the inconsistency of screen layout, we can introduce new param field and utilize format strings with sprintf(3). That is,

#define ADD_COMMAND(cmd, param, msg) add_cmd(#cmd, do_##cmd, msg, param)

Sample usage:

ADD_COMMAND(option, "[name val]",  "Display or set options");

By the way, no tabs are needed. Use spaces instead.

I build this lab0-c using clang for apple-silicon by modifying dudect/cpucycles.h

static inline int64_t cpucycles(void)
{
#if defined(__i386__) || defined(__x86_64__)
    unsigned int hi, lo;
    __asm__ volatile("rdtsc\n\t" : "=a"(lo), "=d"(hi));
    return ((int64_t) lo) | (((int64_t) hi) << 32);
#elif defined(__aarch64__)
    uint64_t val;

    /* According to ARM DDI 0487F.c, from Armv8.0 to Armv8.5 inclusive, the
     * system counter is at least 56 bits wide; from Armv8.6, the counter
     * must be 64 bits wide.  So the system counter could be less than 64
     * bits wide and it is attributed with the flag 'cap_user_time_short'
     * is true.
     */
    asm volatile("mrs %0, cntvct_el0" : "=r" (val));

    return val;

#else
    uint64_t Res;
    asm volatile("mrs %0, cntvct_el0" : "=r"(Res));
    return Res;
#endif
}

But when I tried to ran lldb for qtest, it got hang on line 890 of linenoise.c after enter return. I backtrack the log and found it might have crashed or infitite looping in libsystem_kernel.read function. However, I couldn't find any known issue related to lldb causing libsystem_kernel read hang.

My lldb version is below:

/usr/bin/lldb: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/lldb (for architecture x86_64):        Mach-O 64-bit executable x86_64
/usr/bin/lldb (for architecture arm64e):        Mach-O 64-bit executable arm64e

Below are the log when I ran lldb and backtrack the issue.

lldb qtest                                      
(lldb) target create "qtest"
Current executable set to '/Users/shouenhsiao/sideProject/CPP/lab0-c/qtest' (arm64).
(lldb) b linenoise
Breakpoint 1: where = qtest`linenoise + 56 at linenoise.c:1152:10, address = 0x00000001000052f8
(lldb) r
Process 62297 launched: '/Users/shouenhsiao/sideProject/CPP/lab0-c/qtest' (arm64)
qtest was compiled with optimization - stepping may behave oddly; variables may not be available.
Process 62297 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
    frame #0: 0x00000001000052f8 qtest`linenoise(prompt="cmd> ") at linenoise.c:1152:10 [opt]
   1149     char buf[LINENOISE_MAX_LINE];
   1150     int count;
   1151
-> 1152     if (!isatty(STDIN_FILENO)) {
   1153         /* Not a tty: read from file / pipe. In this mode we don't want any
   1154          * limit to the line size, so we call a function to handle that. */
   1155         return linenoiseNoTTY();
Target 0: (qtest) stopped.
(lldb) c
Process 62297 resuming
cmd> new
Process 62297 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00000001ac6e6538 libsystem_kernel.dylib`read + 8
libsystem_kernel.dylib`read:
->  0x1ac6e6538 <+8>:  b.lo   0x1ac6e6558               ; <+40>
    0x1ac6e653c <+12>: pacibsp
    0x1ac6e6540 <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1ac6e6544 <+20>: mov    x29, sp
Target 0: (qtest) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00000001ac6e6538 libsystem_kernel.dylib`read + 8
    frame #1: 0x0000000100005f7c qtest`linenoiseEdit(stdin_fd=0, stdout_fd=1, buf="new\n", buflen=4096, prompt=<unavailable>) at linenoise.c:890:17 [opt]
    frame #2: 0x0000000100005558 qtest`linenoiseRaw(buf="new\n", buflen=4096, prompt="cmd> ") at linenoise.c:1097:13 [opt]
    frame #3: 0x0000000100005394 qtest`linenoise(prompt="cmd> ") at linenoise.c:1170:17 [opt]
    frame #4: 0x000000010000354c qtest`run_console(infile_name=0x0000000000000000) at console.c:659:27 [opt]
    frame #5: 0x0000000100000b14 qtest`main(argc=1, argv=0x000000016fdff298) at qtest.c:788:16 [opt]
    frame #6: 0x000000010001d0f4 dyld`start + 520
(lldb) f 1
frame #1: 0x0000000100005f7c qtest`linenoiseEdit(stdin_fd=0, stdout_fd=1, buf="new\n", buflen=4096, prompt=<unavailable>) at linenoise.c:890:17 [opt]
   887          int nread;
   888          char seq[3];
   889
-> 890          nread = read(l.ifd, &c, 1);
   891          if (nread <= 0)
   892              return l.len;
   893
(lldb) f 0
frame #0: 0x00000001ac6e6538 libsystem_kernel.dylib`read + 8
libsystem_kernel.dylib`read:
->  0x1ac6e6538 <+8>:  b.lo   0x1ac6e6558               ; <+40>
    0x1ac6e653c <+12>: pacibsp
    0x1ac6e6540 <+16>: stp    x29, x30, [sp, #-0x10]!
    0x1ac6e6544 <+20>: mov    x29, sp
(lldb)

Thank you for any assitance in advance.
(I would delete this issue if this isn't a right place to file a issue. )

Since the status of make test is always 0 (no matter how many scores you get), the pikachu will always show up.

Corresponding logic in main.yml

 run: |
            make test || (cat scripts/weeping.raw ; exit 1)
            cat scripts/pikachu.raw

Cppcheck version: 2.7
Cppcheck report below warning:
report.c:58:18: style: Variable 'msg_name_text' can be declared withconst [constVariable]
static char *msg_name_text[N_MSG] = {

debian 10, bash 5.0.3

$ git commit -m "a bad one"
.git/hooks/commit-msg: line 157: v: invalid indirect expansion

tried on bash 4.4, looks okay

Not sure how to make it work on both version at the moment

Except for the command listed in trace-10-robust.cmd, other functions with "do_" prefix do not consider the accessing to null pointer. The error can be reproduced by posting the command before "new" is called. For instance:

cmd> dm
Warning: Try to access null queue
Segmentation fault occurred.  You dereferenced a NULL or invalid pointerfish: './qtest' terminated by signal SIGABRT (Abort)

In sigsegvhandler(), report() is called, which invocates non-reentrant stdio functions.

I check signal-safety(7) — Linux manual page to determine whether a function is reentrant, and I wonder if this should be taken into consideration in this case.

In my opinion, using write() to stderr to replace stdio functions might be a solution.

File list.h follows kernel-doc comments, which allows the generation of API documentation extracted from the comments. However, file queue.h does not, and it would be nice to enforce the kernel-doc formatted documentation for functions.

Expected outcome:

1. Rewrite the comments in file queue.h which follows kernel-doc comments.
2. Simplify the comments in file queue.c: Only one-line summary should be kept as the comments. The programmers should read the generated documentation while modifying queue.c.
3. Move q_release_element from file queue.c to queue.h as a static inline function.

When I make with SANITIZER=1 and run the trace trace-17-complexity.cmd, the result shows that there exist global buffer overflow:

$ ./qtest -f traces/trace-17-complexity.cmd
cmd> # Test if q_insert_tail and q_size is constant time complexity
cmd> option simulation 1
=================================================================
==13327==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555aa21519c0 at pc 0x555aa1f4282c bp 0x7ffde162b170 sp 0x7ffde162b160
READ of size 4 at 0x555aa21519c0 thread T0
    #0 0x555aa1f4282b in do_option_cmd /home/jtsai/linux2020/lab0-c/console.c:368
    #1 0x555aa1f41448 in interpret_cmda /home/jtsai/linux2020/lab0-c/console.c:220
    #2 0x555aa1f41e4c in interpret_cmd /home/jtsai/linux2020/lab0-c/console.c:243
    #3 0x555aa1f42b35 in cmd_select /home/jtsai/linux2020/lab0-c/console.c:571
    #4 0x555aa1f42f52 in run_console /home/jtsai/linux2020/lab0-c/console.c:630
    #5 0x555aa1f4006b in main /home/jtsai/linux2020/lab0-c/qtest.c:770
    #6 0x7fd4aa4abb96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)
    #7 0x555aa1f3d7d9 in _start (/home/jtsai/linux2020/lab0-c/qtest+0x67d9)

0x555aa21519c1 is located 0 bytes to the right of global variable 'simulation' defined in 'console.c:20:6' (0x555aa21519c0) of size 1
  'simulation' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow /home/jtsai/linux2020/lab0-c/console.c:368 in do_option_cmd
Shadow bytes around the buggy address:
  0x0aabd44222e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aabd44222f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aabd4422300: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
  0x0aabd4422310: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
  0x0aabd4422320: 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
=>0x0aabd4422330: 00 f9 f9 f9 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
  0x0aabd4422340: 00 00 00 00 01 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9
  0x0aabd4422350: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
  0x0aabd4422360: 00 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9
  0x0aabd4422370: f9 f9 f9 f9 01 f9 f9 f9 f9 f9 f9 f9 01 f9 f9 f9
  0x0aabd4422380: f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==13327==ABORTING

linenoise is now maintained, and it is necessary to keep our copy in git tree. However, we have to make both Arm64 and x86-64 targets functioned as expected.

make test does not pass through each trace. Instead, it just iterate with command prompt.

In conjunction with LeetCode 23. Merge k Sorted Lists, we have to revisit the current command line interpreter. In particular, the following commands should be added or revised.

• show : Show the current queue ID and its contents.
• prev : Show the previous queue ID
• next : Show the next queue ID

The existing commands should perform on the current queue accordingly. After the above is completed, new command merge can be introduced. Consider the command sequence below:

new
ih RAND 10
sort
new
ih RAND 9
sort
new
ih RAND 8
sort
merge

Three queues are present before the command merge, and one queue is left as a result of its execution. Before performing merge, we should go through each queue to check if every queue is sorted in advance.

When q_release_element called from qtest.c,
the free is not test_free, because qtest.c use regular malloc/free.
Then it raise error: munmap_chunk(): invalid pointer

If the q_release_element always free memories from queue.c,
Then, change code to (need #include "harness.h")

static inline void q_release_element(element_t *e)
{
    test_free(e->value);
    test_free(e);
}

can fix the issue.

Otherwise, we have to move q_release_element back to queue.c.
Or, define q_release_element_qtest version for qtest usage.

when I run new command in qtest, can't create a new queue, shell output as follow:

$ ./qtest
cmd> new
l = NULL
cmd> quit
Freeing queue

My environment :

$ uname -a
Linux Legion 5.19.0-38-generic #39~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Mar 17 21:16:15 UTC 2 x86_64 x86_64 x86_64 GNU/Linux