On 11/10/2021 23:03, Steve Wishnousky wrote:
> The proposed changes to fopen ‘a’ seem reasonable for us to implement.
> We’re mostly concerned with preserving backwards compatibility, and I
> don’t see any major impact from ensuring the file access is atomic.

Firstly thanks to Casey for the forward.

If any existing code relies on UCRT's fopen('a') not being atomic, I
would like to hope its maintainer would see sense if this were changed.

> I want to note though that the UCRT does implement fopen ‘x’ (the
 paper
> claims it isn’t implemented). This hasn’t always been the case, but
> support was added in 2017 and backported to all our UCRT versions. Other
> Microsoft CRTs, however, do not have this feature.

I can explain this. If you examine the docs page at
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160,
"x" does not appear in the list of possible choices.

If you scroll down a good bit more, "x" appears in a separate later
list. This seems to me a strange way of categorisation - the second list
appears to be all MS extensions. "x" is ISO C. It is not an extension.

Thanks for the correction, I shall amend the paper.

On a separate note, you say in that docs page that "x" cannot be
combined with "a". This is the same in ISO, however I can see no good
reason why this combination isn't valid. Thoughts?

Niall