yamt commented on code in PR #8997:
URL: https://github.com/apache/nuttx/pull/8997#discussion_r1164362036
##########
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.
my point is that apps for nuttx usually don't specify binary/text.
thus, regardless of this change, they might not work as you expected.
>
> > 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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
