Development #172
Merged
Development #172
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Caution Review failedThe pull request is closed. WalkthroughThis change adds a Random character device driver and a ProcFS virtual filesystem. ProcFS implementation, header, and VFS integration are added and mounted at a runtime path; schedulers (EEVDF, MLFQ) register/unregister processes with ProcFS. RandomInit is invoked from kernel initialization. CharDevice.c no longer includes Console.h. StackUsage and the shell "stacksize" command were removed. Build configuration (CMake) was updated to include ProcFS and the Random driver. Multiple new public procfs and random initialization functions were introduced. Poem
Pre-merge checks❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (1 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (10)
cmake/source.cmake(2 hunks)drivers/Random.c(1 hunks)drivers/Random.h(1 hunks)fs/CharDevice.c(0 hunks)fs/VFS.c(8 hunks)fs/procfs/ProcFS.c(1 hunks)fs/procfs/ProcFS.h(1 hunks)kernel/core/Kernel.c(2 hunks)kernel/sched/EEVDF.c(5 hunks)kernel/sched/MLFQ.c(5 hunks)
💤 Files with no reviewable changes (1)
- fs/CharDevice.c
🧰 Additional context used
🧠 Learnings (25)
📓 Common learnings
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 101
File: kernel/etc/Shell.c:829-837
Timestamp: 2025-08-31T07:06:37.003Z
Learning: assembler-0 is working on optimizing ramfs performance in VoidFrame kernel and wants to implement proper filesystem characteristics like faster lookups, better memory management, and advanced features like copy-on-write and caching.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 132
File: arch/x86_64/syscall/Syscall.c:12-19
Timestamp: 2025-09-19T11:55:43.328Z
Learning: In the VoidFrame kernel project, assembler-0 is implementing basic POSIX-compliant syscalls in ring 0 without user/kernel memory protection, prioritizing getting basic functionality working before adding full security features.
Learnt from: assembler-0
Repo: assembler-0/autocc PR: 33
File: include/utils.hpp:138-190
Timestamp: 2025-08-04T13:24:48.984Z
Learning: The user assembler-0 tends to create wrapper functions during refactoring and sometimes accidentally leaves duplicate implementations. They have a casual, self-aware attitude about coding mistakes and are receptive to feedback about code duplication issues.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: docs/ARCHITECHTURE.md:1-3
Timestamp: 2025-08-31T14:19:11.366Z
Learning: assembler-0 wants to implement deep fault tracing for VoidFrame kernel exceptions (Page Fault, General Protection Fault, Invalid Opcode) instead of just panicking. The current interrupt handler has complete register state available in the Registers struct (defined in arch/x86_64/cpu/Cpu.h) including RBP for stack walking, RIP for fault location, and error codes for analysis.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 80
File: README.md:7-8
Timestamp: 2025-08-13T08:43:54.750Z
Learning: User assembler-0 is working on VoidFrame kernel with a tight deadline (2-3 days before summer ends) and specifically requested runtime safety checks similar to __stack_chk_fail but for deadlocks and other kernel issues. The kernel already has extensive safety mechanisms including stack canaries, guard pages, heap integrity checks, and process security validation.
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
📚 Learning: 2025-09-01T02:35:28.353Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: fs/VFS.c:331-335
Timestamp: 2025-09-01T02:35:28.353Z
Learning: VfsIsFile function was initially implemented as a placeholder that only checked for mount existence. The proper implementation should follow the same pattern as VfsIsDir: find mount, strip mount path, then use filesystem-specific functions to check if the path points to a file (FS_FILE for RAMFS, Fat12 functions for FAT12).
Applied to files:
cmake/source.cmakefs/VFS.cfs/procfs/ProcFS.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-06T05:31:15.868Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 111
File: kernel/sched/MLFQ.c:1514-1514
Timestamp: 2025-09-06T05:31:15.868Z
Learning: In the MLFQ scheduler, removing MLFQYield() from critical system processes like DynamoX and Astra improves system responsiveness, indicating that the yield mechanism may be too aggressive for system-critical processes that need quick response times.
Applied to files:
kernel/sched/MLFQ.c
📚 Learning: 2025-09-02T00:55:58.224Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T00:55:58.224Z
Learning: The VoidFrame MLFQ scheduler has a critical bug where ProcessRuntimePath uses FormatS() which returns a static buffer, causing all processes to share the same path string. This results in process directory cleanup operations affecting the wrong directories - killing one process can delete another process's /Runtime/Processes directory because they all point to the same FormatS static buffer.
Applied to files:
kernel/sched/MLFQ.c
📚 Learning: 2025-09-02T00:55:58.224Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T00:55:58.224Z
Learning: The VoidFrame MLFQ ProcessRuntimePath bug occurs because: 1) ProcessRuntimePath is defined as char* (not char array), 2) All processes get assigned the same FormatS static buffer pointer, 3) Directory cleanup via VfsDelete happens during TerminateProcess() not final cleanup, 4) When terminating a process, VfsDelete uses whatever path is currently in the shared static buffer, causing wrong directories to be deleted. Fix requires either changing ProcessRuntimePath to char array or using dynamic allocation.
Applied to files:
kernel/sched/MLFQ.cfs/procfs/ProcFS.hkernel/sched/EEVDF.c
📚 Learning: 2025-09-02T02:37:06.993Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.h:153-154
Timestamp: 2025-09-02T02:37:06.993Z
Learning: In VoidFrame MLFQ.c, the ProcessRuntimePath cleanup should happen for both normal exit (ProcessExitStub → TerminateProcess with TERM_NORMAL) and kill (MLFQKillProcess → TerminateProcess with TERM_KILLED) since both go through the same TerminateProcess function which has VfsDelete cleanup code when VF_CONFIG_PROCINFO_AUTO_CLEANUP is enabled. If normal exit leaves directories but kill doesn't, this suggests VfsDelete might be failing silently for normal exits, or there's a race condition in the cleanup logic.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-02T00:55:58.224Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 106
File: kernel/sched/MLFQ.c:691-694
Timestamp: 2025-09-02T00:55:58.224Z
Learning: In VoidFrame's MLFQ.c, line 1076 assigns ProcessRuntimePath using FormatS() which returns a static buffer, causing all processes to share the same path pointer. During cleanup, VfsDelete() can delete the wrong process directory because all ProcessRuntimePath fields point to the same static buffer containing the path of the most recently created process. This causes directory cleanup operations to affect unintended processes.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-11T09:51:32.713Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:32.713Z
Learning: In the VoidFrame kernel (kernel/process/Process.c), avoid using floating-point arithmetic in kernel space. Use fixed-point arithmetic instead with integer scaling (e.g., multiplying by 1000 for 3 decimal places) to avoid FPU state management overhead and potential exceptions.
Applied to files:
kernel/sched/MLFQ.c
📚 Learning: 2025-08-11T09:51:51.217Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 70
File: kernel/process/Process.c:1224-1228
Timestamp: 2025-08-11T09:51:51.217Z
Learning: In VoidFrame kernel, avoid using floating-point arithmetic in kernel space functions like SystemService. Use fixed-point arithmetic instead (e.g., 16.16 format with integer operations) to prevent FPU state corruption, improve performance, and ensure predictable behavior. This is especially important for system-level processes running with PROC_PRIV_SYSTEM privileges.
Applied to files:
kernel/sched/MLFQ.c
📚 Learning: 2025-09-01T01:10:22.123Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: README.md:9-9
Timestamp: 2025-09-01T01:10:22.123Z
Learning: The current VoidFrame Registers struct in arch/x86_64/cpu/Cpu.h only saves basic GPRs, segment registers, and exception context (interrupt_number, error_code, rip, cs, rflags, rsp, ss). It's missing critical registers for deep fault tracing: SIMD registers (XMM/YMM/ZMM), control registers (CR0/CR2/CR3/CR4), debug registers (DR0-DR7), and extended FPU state. The struct has a "DO NOT TOUCH" comment indicating it must match interrupt ASM stack layout.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-01T08:17:56.769Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:17:56.769Z
Learning: In VoidFrame's Cerberus security system, CerberusRegisterProcess() causes kernel panics because CerberusInstallStackCanary() performs direct memory writes (*canary_ptr = STACK_CANARY_VALUE) during process creation. The stack memory may not be fully mapped/accessible at this point, causing page faults in critical kernel context. The fix is to either defer canary installation, add memory mapping validation, or skip canary installation during process registration.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: In VoidFrame's process cleanup system, `CleanupTerminatedProcesses()` must skip (using `continue`) when encountering non-zombie processes in the termination queue, as continuing with `FastMemset()` on non-zombie processes causes memory corruption and kernel crashes.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-07T11:41:54.644Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 119
File: kernel/sched/MLFQ.c:1607-1621
Timestamp: 2025-09-07T11:41:54.644Z
Learning: Cerberus causes processes to get "stuck" rather than crash because it performs blocking VFS I/O operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths like CerberusPreScheduleCheck() and CerberusTick(), causing page faults and hangs during context switches instead of clean termination.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-11T07:18:24.614Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 69
File: kernel/etc/Shell.c:82-86
Timestamp: 2025-08-11T07:18:24.614Z
Learning: The order of operations in VoidFrame's `TerminateProcess()` is critical: the process state must be set to PROC_ZOMBIE before adding to the termination queue with a memory barrier between them, otherwise CleanupTerminatedProcesses may process the entry before the zombie state is set.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-09-01T08:01:39.969Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 105
File: meson.build:252-257
Timestamp: 2025-09-01T08:01:39.969Z
Learning: Cerberus memory protection system causes kernel panics not because of fault analysis but because it performs VFS operations (VfsCreateDir, VfsAppendFile, VfsWriteFile) in critical scheduler paths. CerberusPreScheduleCheck() runs before every context switch and CerberusTick() runs every 10 scheduler ticks, both potentially triggering VFS I/O that can cause page faults. VFS operations should be deferred or made optional to avoid crashes in scheduler context.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-09T10:31:44.439Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 58
File: drivers/VesaBIOSExtension.c:77-85
Timestamp: 2025-08-09T10:31:44.439Z
Learning: In VoidFrame kernel, process stacks are allocated using VMemAllocWithGuards() which returns virtual addresses, but TerminateProcess incorrectly uses FreePage() (which expects physical addresses) to free them, causing "Page index out of bounds" errors. The correct function to use is VMemFreeWithGuards(proc->stack, STACK_SIZE).
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: VoidFrame's TerminateProcess function in Process.c only checks if the caller has PROC_PRIV_SYSTEM privilege but doesn't compare caller vs target privilege levels, allowing supervisor processes like the shell to incorrectly kill system-level processes.
Applied to files:
kernel/sched/MLFQ.c
📚 Learning: 2025-08-10T08:52:13.313Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 63
File: kernel/etc/Shell.c:24-28
Timestamp: 2025-08-10T08:52:13.313Z
Learning: In VoidFrame's Process.c, PIDs are allocated using `__sync_fetch_and_add(&next_pid, 1)` which only increments and never reuses freed PIDs, causing PID exhaustion after MAX_PROCESSES terminations.
Applied to files:
kernel/sched/MLFQ.cfs/procfs/ProcFS.hkernel/sched/EEVDF.c
📚 Learning: 2025-09-01T05:15:45.860Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 104
File: kernel/process/Process.c:1074-1075
Timestamp: 2025-09-01T05:15:45.860Z
Learning: In the VoidFrame kernel Process.c, the ProcessRuntimePath field uses FormatS() which returns a static buffer. While technically this creates a race condition where all processes could share the same path memory, the user has tested alternatives and they cause system failures. The current implementation works reliably in practice because the path is used immediately after assignment before FormatS() is called again.
Applied to files:
kernel/sched/MLFQ.ckernel/sched/EEVDF.c
📚 Learning: 2025-08-17T08:16:43.539Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 93
File: kernel/memory/VMem.c:72-79
Timestamp: 2025-08-17T08:16:43.539Z
Learning: In VoidFrame kernel, VMemGetPhysAddr and related page table walking functions were causing panics because they assumed identity mapping existed for physical addresses < IDENTITY_MAP_SIZE (4GB), but the bootloader doesn't provide this 1:1 mapping. The fix is to remove all identity mapping assumptions and always use PHYS_TO_VIRT() for page table access in functions like VMemGetPageTablePhys, VMemMap, VMemMapHuge, VMemGetPhysAddr, VMemUnmap, VMemMapMMIO, and VMemUnmapMMIO.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:19:55.274Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:19:55.274Z
Learning: VMemUnmapMMIO in VoidFrame kernel should use the same page table access pattern as the working VMemUnmap function: `uint64_t* pt_table = (uint64_t*)(pt_phys + KERNEL_VIRTUAL_OFFSET);` rather than PHYS_TO_VIRT macro or identity mapping checks.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-13T07:17:35.941Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 79
File: drivers/PCI/PCI.c:154-154
Timestamp: 2025-08-13T07:17:35.941Z
Learning: In VoidFrame kernel, VMemGetPageTablePhys uses a 3-level hierarchy: Level 0 = PML4->PDP, Level 1 = PDP->PD, Level 2 = PD->PT. To access Page Tables, always use level=2, not level=1.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-07-16T01:04:23.790Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 47
File: kernel/core/Kernel.c:434-434
Timestamp: 2025-07-16T01:04:23.790Z
Learning: VMemAlloc() in VoidFrame kernel fails with error code -2 (VMEM_ERROR_INVALID_ADDR) due to virtual address space layout conflict where the heap start address (_bss_end + KERNEL_VIRTUAL_OFFSET + 1MB margin) exceeds VIRT_ADDR_SPACE_END (0xFFFFFFFF80000000ULL), causing VMemMap validation to fail.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-12T02:13:46.266Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 72
File: arch/x86_64/syscall/SyscallEntry.asm:24-30
Timestamp: 2025-08-12T02:13:46.266Z
Learning: User assembler-0 has existing ELF infrastructure in VoidFrame kernel with Elf.h header definitions and CreateProcess() function that properly sets up process context including stack allocation, ProcessExitStub return address, and register initialization. The issue was missing ELF loader implementation, not compilation problems.
Applied to files:
kernel/sched/EEVDF.c
📚 Learning: 2025-08-31T14:19:11.366Z
Learnt from: assembler-0
Repo: assembler-0/VoidFrame PR: 103
File: docs/ARCHITECHTURE.md:1-3
Timestamp: 2025-08-31T14:19:11.366Z
Learning: assembler-0 wants to implement deep fault tracing for VoidFrame kernel exceptions (Page Fault, General Protection Fault, Invalid Opcode) instead of just panicking. The current interrupt handler has complete register state available in the Registers struct (defined in arch/x86_64/cpu/Cpu.h) including RBP for stack walking, RIP for fault location, and error codes for analysis.
Applied to files:
kernel/sched/EEVDF.c
🧬 Code graph analysis (8)
drivers/Random.h (1)
drivers/Random.c (1)
RandomInit(32-39)
drivers/Random.c (2)
crypto/RNG.c (4)
rdrand_supported(35-39)rdrand16(41-45)xoroshiro128plus(10-18)rng_seed(28-33)fs/CharDevice.c (1)
CharDeviceRegister(14-20)
kernel/core/Kernel.c (3)
kernel/etc/Console.c (2)
PrintKernel(198-211)PrintKernelSuccess(225-230)mm/dynamic/rust/src/ffi.rs (1)
PrintKernel(12-12)drivers/Random.c (1)
RandomInit(32-39)
fs/VFS.c (5)
fs/procfs/ProcFS.c (6)
ProcFSInit(13-16)ProcfsMount(48-52)ProcfsReadFile(54-105)ProcfsWriteFile(107-112)ProcfsListDir(114-146)ProcfsIsDir(148-174)fs/FileSystem.c (1)
FileSystemRegister(13-22)kernel/etc/Console.c (1)
PrintKernel(198-211)drivers/Serial.c (1)
SerialWrite(173-182)kernel/etc/StringOps.c (1)
FastStrCmp(39-49)
kernel/sched/MLFQ.c (2)
fs/procfs/ProcFS.c (2)
ProcFSUnregisterProcess(29-46)ProcFSRegisterProcess(18-27)mm/security/Cerberus.c (1)
CerberusUnregisterProcess(110-134)
fs/procfs/ProcFS.h (1)
fs/procfs/ProcFS.c (8)
ProcFSInit(13-16)ProcFSRegisterProcess(18-27)ProcFSUnregisterProcess(29-46)ProcfsMount(48-52)ProcfsReadFile(54-105)ProcfsWriteFile(107-112)ProcfsListDir(114-146)ProcfsIsDir(148-174)
fs/procfs/ProcFS.c (6)
kernel/etc/Console.c (1)
PrintKernelF(272-279)include/stdlib.h (1)
atoi(4-30)kernel/sched/Scheduler.c (1)
GetCurrentProcessByPID(45-53)kernel/etc/StringOps.c (1)
FastStrCmp(39-49)kernel/etc/Format.c (1)
FormatA(233-239)mm/MemOps.c (1)
FastMemcpy(51-70)
kernel/sched/EEVDF.c (2)
fs/procfs/ProcFS.c (2)
ProcFSRegisterProcess(18-27)ProcFSUnregisterProcess(29-46)mm/security/Cerberus.c (1)
CerberusUnregisterProcess(110-134)
🪛 Clang (14.0.6)
drivers/Random.h
[error] 4-4: 'stdint.h' file not found
(clang-diagnostic-error)
drivers/Random.c
[warning] 5-5: parameter 'dev' is unused
(misc-unused-parameters)
[warning] 5-5: parameter 'buffer' is unused
(misc-unused-parameters)
[warning] 5-5: parameter 'size' is unused
(misc-unused-parameters)
[warning] 7-7: if with identical then and else branches
(bugprone-branch-clone)
[note] 15-15: else branch starts here
(clang)
[warning] 26-26: variable 'g_random_device' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
fs/VFS.c
[note] 206-206: end of the original
(clang)
[note] 206-206: clone 1 starts here
(clang)
[note] 241-241: end of the original
(clang)
[note] 241-241: clone 1 starts here
(clang)
fs/procfs/ProcFS.c
[warning] 11-11: variable 'proc_list_head' is non-const and globally accessible, consider making it const
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 11-11: variable 'proc_list_head' provides global access to a non-const object; consider making the pointed-to data 'const'
(cppcoreguidelines-avoid-non-const-global-variables)
[warning] 18-18: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 18-18: parameter 'data' is unused
(misc-unused-parameters)
[warning] 19-19: integer to pointer cast pessimizes optimization opportunities
(performance-no-int-to-ptr)
[warning] 29-29: parameter 'pid' is unused
(misc-unused-parameters)
[warning] 31-31: variable 'prev' is not initialized
(cppcoreguidelines-init-variables)
[warning] 54-54: parameter 'max_size' is unused
(misc-unused-parameters)
[warning] 55-55: statement should be inside braces
(readability-braces-around-statements)
[warning] 57-57: 16 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 58-58: variable name 'i' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 59-59: variable name 'j' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 60-60: 15 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 65-65: statement should be inside braces
(readability-braces-around-statements)
[warning] 75-75: 1024 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 78-78: variable 'len' is not initialized
(cppcoreguidelines-init-variables)
[warning] 107-107: parameter 'size' is unused
(misc-unused-parameters)
[warning] 125-125: 16 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 126-126: variable name 'i' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 127-127: variable name 'j' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 128-128: 15 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 154-154: 16 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
[warning] 155-155: variable name 'i' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 156-156: variable name 'j' is too short, expected at least 3 characters
(readability-identifier-length)
[warning] 157-157: 15 is a magic number; consider replacing it with a named constant
(cppcoreguidelines-avoid-magic-numbers,readability-magic-numbers)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: build
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
ProcFS & DevFS
Summary by CodeRabbit
New Features
Refactor
Documentation