Обсуждение: Check some unchecked fclose() results
Hi, This morning, while reading through recent commits, I noticed that 69c57466a added a check for fclose(), with the explanationthat “write errors (like ENOSPC) may not be reported until close time.” More generally, an fclose() failure canalso reflect an earlier buffered write or flush failure that is only reported when the stream is closed. So it seems worthchecking these calls in other file-writing paths as well. So I did a quick search through the source tree, and I found several other fclose() calls whose results are not checked.This patch fixes some of them. My criteria for including cases in this patch were basically: * only output file descriptors * code paths where the logic is relatively clear and easy to handle If this patch gets processed, I would be happy to spend more time handling the remaining cases. Or, if committers think allremaining cases should be included in this patch, I would also be happy to expand it. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
> On Mar 23, 2026, at 10:04, Chao Li <li.evan.chao@gmail.com> wrote: > > Hi, > > This morning, while reading through recent commits, I noticed that 69c57466a added a check for fclose(), with the explanationthat “write errors (like ENOSPC) may not be reported until close time.” More generally, an fclose() failure canalso reflect an earlier buffered write or flush failure that is only reported when the stream is closed. So it seems worthchecking these calls in other file-writing paths as well. > > So I did a quick search through the source tree, and I found several other fclose() calls whose results are not checked.This patch fixes some of them. > > My criteria for including cases in this patch were basically: > > * only output file descriptors > * code paths where the logic is relatively clear and easy to handle > > If this patch gets processed, I would be happy to spend more time handling the remaining cases. Or, if committers thinkall remaining cases should be included in this patch, I would also be happy to expand it. > Forgot to attach the patch file. Here comes it. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
Вложения
On 3/23/26 3:22 AM, Chao Li wrote: >> My criteria for including cases in this patch were basically: >> >> * only output file descriptors >> * code paths where the logic is relatively clear and easy to handle Those criteria are not enough as can be evidenced from some of the cases which you patched. I do not see why you would want to error out in the following two cases: 1. When writing to e.g. a log file and we do not call pg_fatal() if a write fails. Then it makes no sense to die on failed fclose(). 2. When creating an empty file. I could be wrong here but in that case fclose() cannot fail. Arguably maybe we should use open() and close() then instead of fopen() and fclose() but handling an error which can never happen does not add any value. Please review your patches a bit careful before submitting. You are doing some good work with finding bugs and reviewing patches but it is clear you do not spend enough time per mail making sure it is not a false positive. -- Andreas Karlsson Percona
> On Apr 2, 2026, at 09:16, Andreas Karlsson <andreas@proxel.se> wrote: > > On 3/23/26 3:22 AM, Chao Li wrote: >>> My criteria for including cases in this patch were basically: >>> >>> * only output file descriptors >>> * code paths where the logic is relatively clear and easy to handle > > Those criteria are not enough as can be evidenced from some of the cases which you patched. I do not see why you wouldwant to error out in the following two cases: > Thanks for noticing this patch. > 1. When writing to e.g. a log file and we do not call pg_fatal() if a write fails. Then it makes no sense to die on failedfclose(). > That’s a good point. I think you referred to the change in pg_dumpall.c and postmaster.c. I didn’t consider that point whenI wrote the patch. But I think it’s arguable. Like in pg_dumpall.c, there are a lot of fprintf, check results of everyfprintf might be redundant, checking a single fclose() might be cleaner. Anyway, I don’t want to argue hard for that. > 2. When creating an empty file. I could be wrong here but in that case fclose() cannot fail. Arguably maybe we should useopen() and close() then instead of fopen() and fclose() but handling an error which can never happen does not add anyvalue. > Even if creating an empty file, fclose() could still possible fail. For example, creating an empty on a network storage,while fclose(), the network connection might be broken, then fclose() could fail. > Please review your patches a bit careful before submitting. You are doing some good work with finding bugs and reviewingpatches but it is clear you do not spend enough time per mail making sure it is not a false positive. > I might have missed some points while working on the patch, but I’m not sure how you concluded that I didn’t spend enoughtime on it. I did make some “too quick” mistakes in my first few months working on the hacker work. Since then, I havemade it a rule to do self-review, build, and testing for every patch before sending it out. Of course, I am still human,I cannot guarantee that I will never make mistakes. But your comments made me realize that a cleanup patch covering all fclose() is not a good idea. Each case needs to be evaluatedseparately, so a broad cleanup patch would be hard to get processed. For that reason, I am withdrawing this patch. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/