205 lines
6.3 KiB
Markdown
Executable File
205 lines
6.3 KiB
Markdown
Executable File
# Logging Audit Guide for Hectic
|
|
|
|
This guide provides a systematic approach to auditing and improving logging in existing functions of the Hectic library.
|
|
|
|
## Checklist for Function Audit
|
|
|
|
### 1. Basic Logging Check
|
|
|
|
- [ ] Function has entry logging (DEBUG or TRACE level)
|
|
- [ ] Function has result/exit logging
|
|
- [ ] Failures and errors are logged with appropriate levels (WARN or EXCEPTION)
|
|
- [ ] Intermediate steps are logged at TRACE or DEBUG level
|
|
- [ ] Successful operation completions are logged at LOG level
|
|
|
|
### 2. Level Consistency Check
|
|
|
|
- [ ] `LOG_LEVEL_TRACE` is used for detailed execution tracking
|
|
- [ ] `LOG_LEVEL_DEBUG` is used for significant internal steps
|
|
- [ ] `LOG_LEVEL_LOG` is used for important operational events and successful operation completions
|
|
- [ ] `LOG_LEVEL_INFO` is used *rarely*, only for user-critical events
|
|
- [ ] `LOG_LEVEL_NOTICE` is used *very rarely*, almost not needed for a low-level library
|
|
- [ ] `LOG_LEVEL_WARN` is used for recoverable problems
|
|
- [ ] `LOG_LEVEL_EXCEPTION` is used only for critical errors
|
|
|
|
### 3. Message Formatting Check
|
|
|
|
- [ ] Messages start with a domain prefix (PARSE:, ALLOC:, FORMAT:, etc.)
|
|
- [ ] Message structure follows the pattern "Action: object (details)"
|
|
- [ ] Messages contain sufficient context for understanding (pointers, sizes, values)
|
|
- [ ] Messages don't contain redundant information
|
|
- [ ] Pointers use %p format
|
|
- [ ] Sizes use %zu format
|
|
- [ ] Strings use length limitation when necessary (%.20s)
|
|
- [ ] NULL pointer checks are added before using pointers in logs
|
|
|
|
## Logging Level Usage Rules
|
|
|
|
### TRACE
|
|
- Function calls and exits
|
|
- Detailed loop iteration information
|
|
- Variable values during execution
|
|
- Any detailed debugging information
|
|
|
|
### DEBUG
|
|
- Entries to public API functions
|
|
- Resource allocation and deallocation
|
|
- Key algorithm steps
|
|
- Data processing details
|
|
|
|
### LOG
|
|
- Successful component initialization
|
|
- Completion of significant operations
|
|
- State changes important for operation
|
|
- Key business logic points
|
|
|
|
### INFO (use rarely!)
|
|
- Library startup and shutdown
|
|
- Version and configuration information
|
|
- Extremely important events visible to users
|
|
- Large operations requested by users
|
|
|
|
### NOTICE (almost never use)
|
|
- Events that users should pay attention to
|
|
- Significant planned actions
|
|
|
|
### WARN
|
|
- Unexpected but handled errors
|
|
- Edge cases
|
|
- Warnings about potential problems
|
|
- Use of deprecated APIs
|
|
|
|
### EXCEPTION
|
|
- Serious errors affecting system operation
|
|
- Data integrity violations
|
|
- Resource exhaustion
|
|
- Critical security failures
|
|
|
|
## Audit and Update Process
|
|
|
|
### Step 1: Function Analysis
|
|
|
|
1. Determine the function type:
|
|
- Initialization/resource management function
|
|
- Data processing function
|
|
- Utility function
|
|
- Other
|
|
|
|
2. Identify key logging points:
|
|
- Function entry
|
|
- Parameter checks
|
|
- Main processing steps
|
|
- Error conditions
|
|
- Function exit
|
|
|
|
### Step 2: Update Planning
|
|
|
|
1. Create a list of necessary logs at each level
|
|
2. Determine the right prefixes for each message type
|
|
3. Prepare detailed messages with necessary context
|
|
4. Ensure parameter checks are logged before use
|
|
|
|
### Step 3: Implementing Changes
|
|
|
|
1. Add/update function entry logging
|
|
2. Add/update input parameter checks
|
|
3. Update intermediate step logging
|
|
4. Add/update error condition logging
|
|
5. Add/update result logging
|
|
|
|
### Step 4: Testing
|
|
|
|
1. Check message output correctness
|
|
2. Verify proper level usage
|
|
3. Check that all necessary information is included in logs
|
|
4. Compare with other already updated functions for consistency
|
|
|
|
## Examples for Typical Functions
|
|
|
|
### Memory Allocation Function:
|
|
|
|
```c
|
|
void* memory_function__(const char *file, const char *func, int line, size_t size) {
|
|
// Function entry
|
|
raise_message(LOG_LEVEL_DEBUG, file, func, line,
|
|
"ALLOC: Requesting memory allocation (size: %zu bytes)", size);
|
|
|
|
// Parameter check
|
|
if (size == 0) {
|
|
raise_message(LOG_LEVEL_WARN, file, func, line,
|
|
"ALLOC: Zero-sized memory allocation requested");
|
|
return NULL;
|
|
}
|
|
|
|
// Memory allocation
|
|
void *ptr = malloc(size);
|
|
if (!ptr) {
|
|
raise_message(LOG_LEVEL_EXCEPTION, file, func, line,
|
|
"ALLOC: Memory allocation failed (requested: %zu bytes)", size);
|
|
return NULL;
|
|
}
|
|
|
|
// Result
|
|
raise_message(LOG_LEVEL_LOG, file, func, line,
|
|
"ALLOC: Memory allocated successfully (address: %p, size: %zu bytes)",
|
|
ptr, size);
|
|
return ptr;
|
|
}
|
|
```
|
|
|
|
### Data Conversion Function:
|
|
|
|
```c
|
|
char* convert_function__(const char *file, const char *func, int line,
|
|
const void *input, size_t input_size) {
|
|
// Function entry
|
|
raise_message(LOG_LEVEL_DEBUG, file, func, line,
|
|
"CONVERT: Starting data conversion (input: %p, size: %zu)",
|
|
input, input_size);
|
|
|
|
// Parameter check
|
|
if (!input) {
|
|
raise_message(LOG_LEVEL_WARN, file, func, line,
|
|
"CONVERT: NULL input provided");
|
|
return NULL;
|
|
}
|
|
|
|
if (input_size == 0) {
|
|
raise_message(LOG_LEVEL_WARN, file, func, line,
|
|
"CONVERT: Zero input size provided");
|
|
return NULL;
|
|
}
|
|
|
|
// Processing start
|
|
raise_message(LOG_LEVEL_TRACE, file, func, line,
|
|
"CONVERT: Processing input data...");
|
|
|
|
// Processing...
|
|
|
|
// Result
|
|
char *result = NULL; // conversion result
|
|
if (!result) {
|
|
raise_message(LOG_LEVEL_WARN, file, func, line,
|
|
"CONVERT: Conversion failed");
|
|
return NULL;
|
|
}
|
|
|
|
raise_message(LOG_LEVEL_LOG, file, func, line,
|
|
"CONVERT: Data conversion completed successfully (result: %p)", result);
|
|
return result;
|
|
}
|
|
```
|
|
|
|
## Update Priorities
|
|
|
|
Recommended order for updating functions:
|
|
|
|
1. Memory management functions (`arena_*`)
|
|
2. Parsing functions (`json_parse_*`)
|
|
3. Formatting functions (`json_to_string_*`)
|
|
4. Data processing functions (`slice_*`)
|
|
5. Utility functions
|
|
|
|
## Conclusion
|
|
|
|
Consistent application of these recommendations to functions in the library will significantly improve logging quality and facilitate debugging and code maintenance in the future. |