bytecodealliance
move stdio fd handle checking in fd_determine_type_rights to ensure type is properly set before return
Before this change, fd_determine_type_rights would return early upon dealing with a stdio file handle without giving it any type (therefore being left as a __WASI_FILETYPE_UNKNOWN). This would end up having repercussions on wasi-sdk's implementation of vfprintf, which doesn't register line breaks properly if the file it's writing to (stdout in the case of printf) isn't a tty, which is mainly checked by seeing if the file is a CHARACTER_DEVICE.
This would end up having repercussions on wasi-sdk's implementation of vfprintf, which doesn't register line breaks properly if the file it's writing to (stdout in the case of printf) isn't a tty, which is mainly checked by seeing if the file is a CHARACTER_DEVICE.
Would you mind pointing out the source code in wasi-libc related to that?
fd_determine_type_rightswould return early upon dealing with a stdio file handle without giving it any type
IIUC, *type = buf.st_filetype; is the key to ⬆️ problem. So how about moving L527~L540 to L469 and return directly.
This would end up having repercussions on wasi-sdk's implementation of vfprintf, which doesn't register line breaks properly if the file it's writing to (stdout in the case of printf) isn't a tty, which is mainly checked by seeing if the file is a CHARACTER_DEVICE.
Would you mind pointing out the source code in wasi-libc related to that?
https://github.com/WebAssembly/wasi-libc/blob/1377a93acea031acd9b6e77a830360d88477319c/libc-bottom-half/sources/isatty.c
fd_determine_type_rightswould return early upon dealing with a stdio file handle without giving it any typeIIUC,
*type = buf.st_filetype;is the key to ⬆️ problem. So how about moving L527~L540 to L469 and return directly.
i feel it's better to revert https://github.com/bytecodealliance/wasm-micro-runtime/pull/3694 and investigate the original issue because it was based on a broken experiment: https://github.com/bytecodealliance/wasm-micro-runtime/issues/3686#issuecomment-2998903186
I feel this PR is primarily about ensuring *type is assigned as an output parameter, which the original code missed. We might want to reopen the discussion on 3686.