domains / families / software-engineering / c-pro

c-pro

combined

Write efficient C code with proper memory management, pointer Review and implement C systems code with explicit memory ownership, pointer bounds, error handling, and measured performance.

When to use

• Working on c pro tasks or workflows
• Needing guidance, best practices, or checklists for c pro
• Reviewing allocation lifetime, pointer arithmetic, buffer bounds, or error paths in C.
• Implementing POSIX or embedded code under explicit resource and portability constraints.
• Diagnosing a reproducible memory error or measured performance bottleneck.

When not to use

• The task is unrelated to c pro
• You need a different domain or tool outside this scope
• This entrypoint has no bundled reference files; do not claim to have read absent scripts or playbooks.
• Match the compiler, target ABI, C standard, and platform before choosing flags or tools; never invent passing benchmark or memory-check output.
• Use this skill only when the task clearly matches the scope described above.
• Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
• Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

Skill page

Conflict

Both copies share the same core C systems programming checklist (memory management, pointer arithmetic, POSIX, embedded, pthreads, valgrind/gdb, C99/C11, Makefile flags, include guards, unit tests). However, the sickn33 copy adds material constraints and steps the rmyndharis copy lacks: explicit ownership documentation (release each owned allocation exactly once, distinguish borrowed pointers), a requirement to provide actual sanitizer/Valgrind output or state that runtime checks were not run, a Limitations section forbidding invented benchmark/memory-check output, and a requirement to match compiler/ABI/standard before choosing flags. The rmyndharis copy is a shorter, more generic version of the same procedure. Crowning one would hide the stricter, more explicit ownership and verification constraints in the other.