Andrew Schwartzmeyer created MESOS-8347:
-------------------------------------------
Summary: Fix os::open() semantics on Windows
Key: MESOS-8347
URL: https://issues.apache.org/jira/browse/MESOS-8347
Project: Mesos
Issue Type: Bug
Environment: Windows 10
Reporter: Andrew Schwartzmeyer
Assignee: Andrew Schwartzmeyer
The default semantics of {{open}} and {{fdopen}} on Windows is to use "text
translation" mode, which means that for each end-of-line, instead of writing
the data the user sent, it instead writes a Windows-style CR/LF line ending.
[Text and Binary Mode File
I/O|https://docs.microsoft.com/en-us/cpp/c-runtime-library/text-and-binary-mode-file-i-o]
[::open|https://msdn.microsoft.com/en-us/library/z0kc8e3z.aspx]
This leads to problems in Mesos because all the existing code expects "POSIX
semantics" (or really, the semantics where your data is written as it is
given). To date, we've fixed half a dozen locations where we call Stout's
{{os::open}} with an {{#ifdef __WINDOWS__}} to add the {{O_BINARY}} flag to
disable text translation. At this point, we should instead just make this the
default semantics of {{os::open}}, and address the possibility of needing text
translation in the future (precedent shows it to be unlikely).
Things that were previously affected by this:
* protobuf::write
* net::download (which also uses fdopen directly and so needs {{wb}} mode)
* os::write (so we'd already made the decision that stout should behave this
way)
* status_update_manager_process.hpp
We're making the conscious decision to _not_ use the function {{_set_fmode}} to
change the default mode for newly opened files, because we would have to do
this carefully for each process, and that probably means checking and setting
it in stout anyway. Since we have stout (and thus a uniform way to access
::open, though not ::fdopen, but it's only used once!), it's just as easy to
add the {{O_BINARY}} flag to the call.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)