You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@nuttx.apache.org by "xiaoxiang781216 (via GitHub)" <gi...@apache.org> on 2023/04/12 16:05:30 UTC
[GitHub] [nuttx] xiaoxiang781216 commented on a diff in pull request #8997: sim/hostfs: pass flag O_BINARY to host
xiaoxiang781216 commented on code in PR #8997:
URL: https://github.com/apache/nuttx/pull/8997#discussion_r1164348241
##########
arch/sim/src/sim/win/sim_hostfs.c:
##########
@@ -120,6 +120,11 @@ int host_open(const char *pathname, int flags, nuttx_mode_t mode)
mapflags |= O_TRUNC;
}
+ if (flags & NUTTX_O_BINARY)
+ {
+ mapflags |= O_BINARY;
+ }
Review Comment:
> > > the semantics of nuttx (and many of unix-like systems) is "always O_BINARY". it seems a bit awkward to distinguish binary/text only for hostfs. isn't it simpler to always use O_BINARY in hostfs for windows?
> >
> >
> > we have some windows developers hope that the hosfs could be support both un/translated, I think bring back the O_BINARY define is a simply resolution for this case...
>
> what apps are they using? usually apps for nuttx (or unix in general) doesn't specify their text/binary intention. iirc posix even states fopen "b" mode is no-op.
>
If you don't pass O_BINARY on Windows, Windows will do the \n<->\r\n. By default, Windows do \n <-> \r\n converson, but Linux/macOS not. We need shield OS difference to keep the consistent behaviour.
> i guess an alternative is to have a mount flag of hostfs.
Option isn't a good choice here. If you open a file with O_BINARY regardless the simulator run on Linux/macOS/Windows, VFS shouldn't do any conversion.
--
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.
To unsubscribe, e-mail: commits-unsubscribe@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org