Calling close() system call with fd < 3

[visitorckw]

Currently, if the close() system call is invoked with fd < 3, close() won't take any action and won't return an error code of -1. Some programs may need to close stdout or stderr to avoid excessive output. Therefore, the current implementation may lead to users getting unexpected results. However, rv32emu also uses stdout and stderr to output some information. Therefore, directly closing stdout and stderr would result in the loss of relevant output information from rv32emu. Here are two possible ways to address this:

1. close() performs no action but returns an error code of -1.
2. Close stdout and stderr as usual and allow rv32emu to lose output information.

[banglday]

Currently, if the close() system call is invoked with fd < 3, close() won't take any action and won't return an error code of -1. Some programs may need to close stdout or stderr to avoid excessive output. Therefore, the current implementation may lead to users getting unexpected results. However, rv32emu also uses stdout and stderr to output some information. Therefore, directly closing stdout and stderr would result in the loss of relevant output information from rv32emu. Here are two possible ways to address this:

1. close() performs no action but returns an error code of -1.
2. Close stdout and stderr as usual and allow rv32emu to lose output information.

Conflict in This Issue

1. Some user programs may need to close stdout or stderr.
2. rv32emu itself relies on stdout and stderr for its own output.

Because of these two needs, there is a conflict about how close() should behave when fd < 3.

Analysis of the Solutions

Solution 1: Do not actually close, but return an error code (-1)

Advantages:

• stdout and stderr remain open, so rv32emu can continue printing messages or logs.
• User programs get an error code, so they know the close operation was not successful. This avoids them thinking they successfully closed the output channels.
• After seeing the error, user programs can redirect output or do other error handling. This prevents confusion like “I thought it was closed, but it’s still printing.”

Disadvantages:

• This does not match real system behavior exactly. In a typical Unix-like system, calling close(1) or close(2) is allowed. Here, the emulator denies it to keep its own output working.

---

Solution 2: Allow normal closing of stdout and stderr

Advantages:

• This is closer to real Unix behavior (where closing file descriptor 1 or 2 is allowed).
• If a user program really needs to close stdout or stderr, it will behave like on a real system (no further output on those descriptors).

Disadvantages:

• rv32emu’s own output (errors, debug messages, etc.) will be “lost,” because stdout and stderr will actually be closed. This makes debugging or analysis more difficult.
• If rv32emu wants to keep printing messages, it must handle that differently (for example, by opening a new file descriptor or redirecting output), or else lose its log messages.

Option: Redirect rv32emu’s Output Inside the Emulator

How to keep rv32emu’s output even after stdout and stderr are closed?

• At startup, rv32emu could redirect its own logging to other file descriptors (for example, 100 or 101). Then all of rv32emu’s messages go to those custom descriptors.
• Even if the user program closes stdout or stderr, rv32emu can still print to its private descriptors.

---

Solution 3: Add an Emulator Option for Either Behavior

• Provide an emulator parameter (for example, --allow-close-stdio) so the user can choose whether to allow truly closing stdout/stderr.
• By default, do not allow closing and return -1 to protect rv32emu’s output. But if the user really wants to close stdout/stderr, they can enable this option and accept losing rv32emu’s output.

This way, developers, users, and real system behavior can all be supported as needed.

---

Conclusion

To prevent a user program from thinking it closed stdout or stderr when it really did not, the simplest approach is Solution 1: do nothing but return an error code (-1).

• This tells the user program that closing fd < 3 failed, so it will not assume the channels are closed.
• For most needs, where preserving emulator output is important (especially for debugging or analysis), this is a good compromise.

Since rv32emu is often used in teaching and research, being able to see the emulator’s own outputs is very helpful. Thus, returning -1 is recommended by default. If needed, you can provide parameters or redirection mechanisms to allow truly closing the file descriptors in special cases. This maintains a good user experience while still letting people enable the more realistic behavior if they want.

PS: I am trying to reproduce the issue and do some experiment to prove above points. I save all records in this document.