uexterr_format(): simplify output when ext error string is available If the extended error string is provided by kernel, return only the string, which is supposedly enough to identify exact cause of the error. If the string is not provided, print the technically looking gibberish which still allows to identify location with kernel sources. err(3): print extended error if available
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | Should this be false, since the errno is coming from the caller instead of from the kernel? | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | I am not sure. There are syscalls returning error instead of setting errno, and errc() is naturally used with them. I definitely mean this. The question is probably should warnc() and errc() be consistent in this regard. | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 199 | It looks like the \n went missing. This function and verrci have a lot in common. Should they be merged? | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | I'm concerned about a sequence of events like this: (void) some_syscall(42); // Fails with EINVAL and ext err "Not a valid number"
...
if (err = some_library_call()) {
// errc might print "Not a valid number", which wouldn't make sense.
errc(1, err, "some_library_call");
} | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | I understand. In fact it would print right error, and not related extended error. Practically this is not too huge issue, but ok. I reverted the errc() back. | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | How would it know not to print the stale error? The new error may not even come from the kernel. The library might use errnos for its own errors. | |
| lib/libc/gen/err.c | ||
|---|---|---|
| 96 | This is reverted already. | |