Bug 217126
Summary: | Completion of error handling | ||
---|---|---|---|
Product: | Tools | Reporter: | Markus Elfring (Markus.Elfring) |
Component: | Trace-cmd/Kernelshark | Assignee: | Default virtual assignee for Trace-cmd and kernelshark (tools_tracecmd_kernelshark) |
Status: | NEW --- | ||
Severity: | normal | CC: | rostedt |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 6.2.2 | Subsystem: | |
Regression: | No | Bisected commit-id: |
Description
Markus Elfring
2023-03-04 08:19:43 UTC
dirname() is guaranteed to succeed. fclose() : What error handling would you suggest? Really, if it fails, then there's nothing we can do, and that only happens if there's issues elsewhere. So I ignore it. ftruncate() errors are all for a bad fd which is covered by the open. I agree that the strdup()s could use a check. I don't care about the return value of printf(). The pthread code could use checks. I don't care about putchar(). If there's an error with printing, how would you report it? The write in ptp_clock_server is for debugging only. No need to check. So, I will keep this bug open for the strdup() and pthread code. (In reply to Steven Rostedt from comment #1) More return values should be used (according to rules for secure programming). * https://wiki.sei.cmu.edu/confluence/display/c/EXP12-C.+Do+not+ignore+values+returned+by+functions * https://cwe.mitre.org/data/definitions/252.html How will chances evolve to benefit any more also from the means of aspect-oriented software development? https://en.wikipedia.org/wiki/Aspect-oriented_programming The source code is evolving. trace-cmd: Check all strdup() return values https://lore.kernel.org/linux-trace-devel/20230602014539.013dceb2@rorschach.local.home/ |