juniskane commented on pull request #425: URL: https://github.com/apache/incubator-nuttx-apps/pull/425#issuecomment-708995071
Calling fclose() on any of the standard text streams is not undefined behavior, just any use of the stream afterwards (including second fclose() and things like perror() inside library functions, but not the implicit closing of files in process exit). Wording in ISO/IEC 9899:1999 7.19.3.4 hints that standard streams can be closed like any other: _"The value of a pointer to a FILE object is indeterminate after the associated file is closed (including the standard text streams)."_ OpenGroup/POSIX bug tracker has interesting discussion about this: https://www.austingroupbugs.net/view.php?id=555 That shows how the recently added wording you quoted from OpenGroup spec came into being. The code that was in USB console and daemon() is typical for many UNIX daemons so existing applications might contain a similar fclose/dup2/fdopen sequence. Gnulib has close_stdout() explicitly for closing stdout and stderr streams, I guess someone finds that feature useful: https://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/closeout.c Just making fclose() a no-op if applied to any of the three standard streams feels like a suitable fix for this. There might be difficulties with setbuf() and setvbuf(), however, if application sets a buffer in stack and relied on fclose() disassociating it from the stream before exiting code block were buffer was defined. This is probably very rare scenario. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
