Question about `libcrun_error_t *err` input argument requirement
- Dominant language
- C
- Stars
- 4.1k
- Forks
- 444
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 43
Description
Many crun() functions takes ` libcrun_error_t *err` as input argument.
Is there a requirement to set `err` to `NULL` beforehand?
In other words, is it required to do
```
libcrun_error_t err = NULL;
some_crun_function (&err);
```
or is it also fine to do this?
```
libcrun_error_t err;
some_crun_function (&err);
```
For example, it seems this code has the NULL requirement:
https://github.com/containers/crun/blob/0aef8e17e0925806ae4577d9a82a7b326c185910/src/libcrun/linux.c#L1323
because this code
https://github.com/containers/crun/blob/0aef8e17e0925806ae4577d9a82a7b326c185910/src/libcrun/error.c#L104
would otherwise dereference an uninitialized pointer.
If there is such a requirement, then it is not documented in `error_handling.md`
https://github.com/containers/crun/blob/0aef8e17e0925806ae4577d9a82a7b326c185910/design-docs/error_handling.md?plain=1#L1-L20
See also
* https://github.com/containers/crun/issues/2022
that discussed dereferencing an uninitialized pointer because of
```
libcrun_error_t err;
```
in _python/crun_python.c_
Contributor guide
Research direction
Read design-docs/error_handling.md alongside the cited code in src/libcrun/linux.c and src/libcrun/error.c, then compare the call pattern with _python/crun_python.c. Confirm the required initialization behavior and document the requirement, including a safe example, in error_handling.md.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- documentation, operating-systems
- Issue type
- Documentation
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100