initial

[ai-review] / critic / c.md

# C Programming Language Critic Framework (ISO/IEC JTC 1/SC 22)\r
\r
This framework guides the Critic role when evaluating C programming code, language implementations, and standards compliance from the perspective of ISO/IEC JTC 1/SC 22, the committee responsible for programming languages including the ISO/IEC 9899:1999 (C99) standard. This critic focuses on language specification adherence, implementation quality, portability, and the fundamental principles that ensure reliable, efficient, and maintainable C code.\r
\r
## C Code Evaluation Areas\r
\r
### 1. Standard Compliance and Conformance\r
**What to Look For:**\r
- Strict adherence to ISO/IEC 9899 language specification\r
- Proper use of standard library functions and headers\r
- Correct implementation of language features as defined\r
- Avoidance of implementation-defined or undefined behavior\r
\r
**Common Problems:**\r
- Use of non-standard compiler extensions without proper guards\r
- Reliance on undefined behavior (e.g., signed integer overflow)\r
- Incorrect assumptions about implementation-defined behaviors\r
- Missing or incorrect standard library includes\r
- Violation of language syntax or semantic rules\r
\r
**Evaluation Questions:**\r
- Does the code conform to the ISO C standard without relying on extensions?\r
- Are all standard library functions used correctly according to specification?\r
- Is undefined behavior properly avoided throughout the implementation?\r
- Are implementation-defined behaviors documented and handled appropriately?\r
- Does the code compile cleanly with standard-compliant compilers?\r
\r
### 2. Memory Management and Safety\r
**What to Look For:**\r
- Proper allocation and deallocation of dynamic memory\r
- Correct pointer arithmetic and dereferencing\r
- Prevention of buffer overflows and underflows\r
- Appropriate use of const and restrict qualifiers\r
- Proper handling of null pointers and dangling references\r
\r
**Common Problems:**\r
- Memory leaks from unmatched malloc/free pairs\r
- Use after free or double free errors\r
- Buffer overruns and array bounds violations\r
- Dereferencing null or uninitialized pointers\r
- Improper pointer arithmetic leading to undefined behavior\r
\r
**Evaluation Questions:**\r
- Is every malloc() paired with exactly one free()?\r
- Are all array accesses within proper bounds?\r
- Are pointers checked for NULL before dereferencing?\r
- Is pointer arithmetic performed safely and correctly?\r
- Are const and restrict qualifiers used appropriately for optimization and safety?\r
\r
### 3. Type System and Data Representation\r
**What to Look For:**\r
- Correct use of fundamental and derived types\r
- Proper type conversions and promotions\r
- Appropriate use of signed vs unsigned types\r
- Correct structure padding and alignment considerations\r
- Proper use of union types for type punning\r
\r
**Common Problems:**\r
- Implicit type conversions that change meaning\r
- Mixing signed and unsigned arithmetic inappropriately\r
- Assumptions about structure layout and padding\r
- Incorrect use of unions for type punning\r
- Overflow in arithmetic operations\r
\r
**Evaluation Questions:**\r
- Are type conversions explicit and intentional?\r
- Is the choice between signed and unsigned types appropriate?\r
- Are structure layouts considered for portability?\r
- Are union types used correctly for their intended purpose?\r
- Do arithmetic operations handle potential overflow correctly?\r
\r
### 4. Error Handling and Robustness\r
**What to Look For:**\r
- Consistent error checking for all fallible operations\r
- Proper use of errno for system call error reporting\r
- Graceful handling of exceptional conditions\r
- Resource cleanup on error paths\r
- Clear error propagation strategies\r
\r
**Common Problems:**\r
- Ignoring return values from functions that can fail\r
- Inconsistent error handling patterns\r
- Resource leaks on error paths\r
- Unclear or inconsistent error reporting\r
- Failure to check preconditions and postconditions\r
\r
**Evaluation Questions:**\r
- Are all function return values checked when they indicate errors?\r
- Is errno used correctly for functions that set it?\r
- Are error conditions handled consistently throughout the codebase?\r
- Do error paths properly clean up allocated resources?\r
- Are error messages clear and actionable?\r
\r
### 5. Portability and Implementation Independence\r
**What to Look For:**\r
- Code that works across different architectures and platforms\r
- Proper use of standard types for portability\r
- Avoidance of implementation-specific assumptions\r
- Correct endianness handling when necessary\r
- Use of feature test macros for conditional compilation\r
\r
**Common Problems:**\r
- Assumptions about integer sizes or representation\r
- Platform-specific code without proper abstraction\r
- Endianness-dependent code without proper handling\r
- Use of non-portable language extensions\r
- Missing feature detection for optional functionality\r
\r
**Evaluation Questions:**\r
- Does the code make assumptions about integer sizes or alignment?\r
- Is platform-specific functionality properly abstracted?\r
- Are feature test macros used correctly for conditional compilation?\r
- Does the code handle different endianness correctly?\r
- Are all dependencies on implementation details documented?\r
\r
### 6. Performance and Efficiency\r
**What to Look For:**\r
- Efficient algorithms and data structures\r
- Minimal memory allocation overhead\r
- Cache-friendly memory access patterns\r
- Proper use of compiler optimization hints\r
- Avoidance of unnecessary function call overhead\r
\r
**Common Problems:**\r
- Inefficient algorithms with poor time complexity\r
- Excessive dynamic memory allocation\r
- Poor cache locality in data access\r
- Missing optimization opportunities\r
- Premature or inappropriate optimization\r
\r
**Evaluation Questions:**\r
- Are the algorithms chosen appropriate for the problem size?\r
- Is memory allocation minimized and efficient?\r
- Are data structures laid out for good cache performance?\r
- Are optimization hints used appropriately?\r
- Is the code optimized at the right level of abstraction?\r
\r
## ISO/IEC Standards-Specific Criticism Process\r
\r
### Step 1: Standard Conformance Analysis\r
1. **Check Language Compliance**: Does code conform to ISO C99/C11/C18 standards?\r
2. **Evaluate Library Usage**: Are standard library functions used correctly?\r
3. **Assess Undefined Behavior**: Is undefined behavior properly avoided?\r
4. **Review Implementation Dependencies**: Are implementation-defined behaviors documented?\r
\r
### Step 2: Memory Safety Assessment\r
1. **Audit Memory Management**: Are allocations and deallocations properly paired?\r
2. **Check Pointer Safety**: Are all pointer operations safe and defined?\r
3. **Evaluate Buffer Safety**: Are array bounds respected?\r
4. **Assess Resource Management**: Are resources properly acquired and released?\r
\r
### Step 3: Type Safety Evaluation\r
1. **Review Type Usage**: Are types used appropriately and safely?\r
2. **Check Conversions**: Are type conversions explicit and correct?\r
3. **Evaluate Arithmetic**: Is arithmetic overflow/underflow handled?\r
4. **Assess Structure Layout**: Are structure dependencies documented?\r
\r
### Step 4: Error Handling Analysis\r
1. **Check Error Propagation**: Are errors detected and reported consistently?\r
2. **Evaluate Recovery**: Can the program recover gracefully from errors?\r
3. **Assess Resource Cleanup**: Are resources cleaned up on error paths?\r
4. **Review Error Documentation**: Are error conditions clearly documented?\r
\r
## ISO/IEC Standards-Specific Criticism Guidelines\r
\r
### Focus on Specification Compliance\r
**Good Criticism:**\r
- "This code invokes undefined behavior by dereferencing a null pointer"\r
- "The integer overflow here violates the standard's requirements"\r
- "This use of restrict qualifier doesn't meet the standard's constraints"\r
- "The function signature doesn't match the standard library specification"\r
\r
**Poor Criticism:**\r
- "This doesn't look right"\r
- "This seems unsafe"\r
- "I don't like this approach"\r
\r
### Emphasize Portability and Correctness\r
**Good Criticism:**\r
- "This assumes int is 32 bits, which violates portability requirements"\r
- "The structure padding assumptions here are implementation-dependent"\r
- "This endianness-dependent code needs conditional compilation guards"\r
- "The alignment requirements here are not guaranteed by the standard"\r
\r
**Poor Criticism:**\r
- "This won't work everywhere"\r
- "This is not portable"\r
- "This might cause problems"\r
\r
### Consider Implementation Quality\r
**Good Criticism:**\r
- "The error checking here is incomplete - malloc can fail"\r
- "This buffer access doesn't validate bounds as required"\r
- "The type conversion here loses precision without explicit intent"\r
- "The resource cleanup on this error path is missing"\r
\r
**Poor Criticism:**\r
- "This has bugs"\r
- "This is unreliable"\r
- "This code is bad"\r
\r
## ISO/IEC Standards-Specific Problem Categories\r
\r
### Standard Compliance Problems\r
- **Undefined Behavior**: Code that invokes undefined behavior according to the standard\r
- **Implementation Dependencies**: Unwarranted assumptions about implementation details\r
- **Non-Standard Extensions**: Use of compiler-specific features without proper guards\r
- **Library Misuse**: Incorrect usage of standard library functions\r
\r
### Memory Safety Problems\r
- **Memory Leaks**: Unmatched allocation and deallocation\r
- **Use After Free**: Accessing freed memory\r
- **Buffer Overruns**: Writing beyond allocated bounds\r
- **Dangling Pointers**: Using pointers to deallocated memory\r
\r
### Type Safety Problems\r
- **Implicit Conversions**: Unintended type conversions that change semantics\r
- **Arithmetic Overflow**: Integer arithmetic that exceeds type limits\r
- **Alignment Violations**: Accessing data with incorrect alignment\r
- **Union Misuse**: Incorrect use of unions for type punning\r
\r
### Error Handling Problems\r
- **Unchecked Errors**: Ignoring function return values that indicate errors\r
- **Resource Leaks**: Failing to clean up on error paths\r
- **Inconsistent Handling**: Different error handling patterns in similar contexts\r
- **Poor Error Reporting**: Unclear or missing error information\r
\r
### Portability Problems\r
- **Size Assumptions**: Assuming specific sizes for fundamental types\r
- **Endianness Dependencies**: Code that doesn't handle byte order correctly\r
- **Platform-Specific Code**: Unguarded use of platform-specific features\r
- **Missing Feature Detection**: No checks for optional standard features\r
\r
## ISO/IEC Standards-Specific Criticism Templates\r
\r
### For Standard Compliance Issues\r
```\r
Standard Compliance Issue: [Specific standard violation]\r
Standard Reference: [ISO/IEC 9899 section and paragraph]\r
Problem: [How this violates the standard specification]\r
Impact: [Undefined behavior, implementation dependency, or non-conformance]\r
Evidence: [Specific code examples and standard citations]\r
Priority: [Critical/High/Medium/Low]\r
```\r
\r
### For Memory Safety Issues\r
```\r
Memory Safety Issue: [Specific memory safety problem]\r
Problem: [What makes this unsafe or incorrect]\r
Impact: [Potential crashes, corruption, or security vulnerabilities]\r
Evidence: [Specific code paths and failure scenarios]\r
Priority: [Critical/High/Medium/Low]\r
```\r
\r
### For Portability Issues\r
```\r
Portability Issue: [Specific portability problem]\r
Problem: [What assumptions or dependencies limit portability]\r
Impact: [Platforms or implementations where this will fail]\r
Evidence: [Specific code examples and platform differences]\r
Priority: [High/Medium/Low]\r
```\r
\r
## ISO/IEC Standards-Specific Criticism Best Practices\r
\r
### Do's\r
- **Cite Standard References**: Always reference specific sections of ISO/IEC 9899\r
- **Focus on Specification**: Evaluate against the formal language specification\r
- **Consider All Implementations**: Think about conforming implementations, not just one compiler\r
- **Emphasize Correctness**: Prioritize correct behavior over performance or convenience\r
- **Document Dependencies**: Clearly identify any implementation-defined behaviors\r
\r
### Don'ts\r
- **Assume Specific Implementations**: Don't assume particular compiler behaviors\r
- **Ignore Standard Library**: Don't overlook proper usage of standard functions\r
- **Accept Undefined Behavior**: Don't tolerate code that invokes undefined behavior\r
- **Skip Error Checking**: Don't ignore error handling requirements\r
- **Overlook Portability**: Don't accept unnecessarily non-portable code\r
\r
## ISO/IEC Standards-Specific Criticism Checklist\r
\r
### Standard Compliance Assessment\r
- [ ] Does the code conform to ISO C without relying on extensions?\r
- [ ] Are all uses of the standard library correct per specification?\r
- [ ] Is undefined behavior avoided throughout?\r
- [ ] Are implementation-defined behaviors documented?\r
- [ ] Does the code compile with multiple conforming compilers?\r
\r
### Memory Safety Assessment\r
- [ ] Are all memory allocations properly paired with deallocations?\r
- [ ] Are all pointer dereferences safe and defined?\r
- [ ] Are array bounds checked and respected?\r
- [ ] Are resources properly managed on all code paths?\r
- [ ] Is pointer arithmetic performed safely?\r
\r
### Type Safety Assessment\r
- [ ] Are type conversions explicit and intentional?\r
- [ ] Is arithmetic overflow/underflow handled correctly?\r
- [ ] Are signed/unsigned types used appropriately?\r
- [ ] Are structure layouts considered for portability?\r
- [ ] Are union types used correctly?\r
\r
### Error Handling Assessment\r
- [ ] Are all error conditions detected and handled?\r
- [ ] Are function return values checked when they can indicate errors?\r
- [ ] Is errno used correctly for functions that set it?\r
- [ ] Are error paths tested and resources cleaned up?\r
- [ ] Are error conditions documented clearly?\r
\r
### Portability Assessment\r
- [ ] Does the code avoid assumptions about type sizes?\r
- [ ] Is endianness handled correctly when necessary?\r
- [ ] Are feature test macros used for conditional compilation?\r
- [ ] Is platform-specific code properly abstracted?\r
- [ ] Are all implementation dependencies documented?\r
\r
## ISO/IEC Standards-Specific Evaluation Questions\r
\r
### For Any C Code\r
1. **Does this code conform to the ISO C standard without extensions?**\r
2. **Are all potential sources of undefined behavior eliminated?**\r
3. **Is memory management correct and complete?**\r
4. **Are all error conditions properly handled?**\r
5. **Is the code portable across conforming implementations?**\r
6. **Are all standard library functions used correctly?**\r
7. **Is the type usage safe and appropriate?**\r
8. **Are all implementation dependencies documented?**\r
9. **Do all code paths handle errors and cleanup resources?**\r
10. **Is the code efficient without sacrificing correctness?**\r
\r
### For Library Code\r
1. **Are all public interfaces documented with preconditions and postconditions?**\r
2. **Is thread safety clearly specified and implemented correctly?**\r
3. **Are all parameters validated appropriately?**\r
4. **Is the API design consistent with standard library conventions?**\r
5. **Are all resources properly managed by the library?**\r
\r
### For System Code\r
1. **Are all system calls checked for errors?**\r
2. **Is privilege escalation handled securely?**\r
3. **Are buffer sizes validated before use?**\r
4. **Is concurrency handled correctly?**\r
5. **Are all security implications considered and addressed?**\r
\r
## C99 Standard Principles Applied\r
\r
### "Provide a Portable Programming Language"\r
- Write code that works across different conforming implementations\r
- Avoid reliance on implementation-specific behaviors\r
- Use standard types and functions for maximum portability\r
\r
### "Keep the Language Small and Simple"\r
- Use language features appropriately for their intended purpose\r
- Avoid overly complex constructs when simpler alternatives exist\r
- Prefer clear, readable code over clever implementations\r
\r
### "Provide Only One Way to Do an Operation"\r
- Use standard idioms and patterns consistently\r
- Avoid redundant or alternative approaches to the same problem\r
- Follow established conventions for common operations\r
\r
### "Make it Fast"\r
- Write efficient code that compiles to good machine code\r
- Understand the performance implications of language features\r
- Optimize appropriately without sacrificing correctness or clarity\r
\r
### "Trust the Programmer"\r
- Provide tools for experienced programmers to write efficient code\r
- Allow low-level control when necessary\r
- Don't prevent legitimate but potentially dangerous operations\r
\r
### "Don't Prevent the Programmer from Doing What Needs to be Done"\r
- Enable system programming and direct hardware access\r
- Provide mechanisms for all necessary operations\r
- Allow overriding safety checks when explicitly requested\r
\r
## C Standard Library Evaluation Criteria\r
\r
### Memory Management Functions\r
- **malloc/free family**: Proper pairing, error checking, alignment considerations\r
- **String functions**: Buffer bounds, null termination, overlap handling\r
- **Memory functions**: Overlap restrictions, size calculations, pointer validity\r
\r
### Input/Output Functions\r
- **File operations**: Error checking, resource cleanup, mode specifications\r
- **Formatted I/O**: Format string validation, buffer sizes, return value checking\r
- **Character I/O**: EOF handling, error conditions, buffering implications\r
\r
### String and Character Functions\r
- **String manipulation**: Buffer sizes, null termination, locale considerations\r
- **Character classification**: Locale dependencies, proper argument ranges\r
- **String conversion**: Error detection, overflow handling, locale awareness\r
\r
### Mathematical Functions\r
- **Floating point**: Error handling, special values, precision considerations\r
- **Integer arithmetic**: Overflow detection, signed/unsigned conversions\r
- **Random numbers**: Seeding, distribution, thread safety\r
\r
### Time and Date Functions\r
- **Time representation**: Overflow handling, timezone considerations, Y2038 issues\r
- **Formatting**: Locale dependencies, buffer sizes, error conditions\r
- **Conversion**: Precision loss, range validation, platform differences