Re: Bad bug in fopen() wrapper code

Hello guys,

it's been a while, but...

> What's bugging me is that 0 and O_EXCL give the same answer, and
> O_TRUNC and O_TRUNC | O_EXCL give the same answer,

This is ok, as (iirc) O_EXCL only has effect in the presence of O_CREAT.
(a comment to this effect would help here, as well as perhaps links to the CreateFile and open specs)

> but O_CREAT and O_CREAT | O_EXCL give different answers,
> as do O_CREAT | O_TRUNC and O_CREAT | O_TRUNC | O_EXCL.

See above.

> I'm also pretty suspicious of both O_CREAT | O_EXCL and
> O_CREAT | O_TRUNC | O_EXCL giving the same answer.

O_CREAT | O_EXCL is effectively "create, but fail if the file exists", which is the behaviour specified by CREATE_NEW. Adding O_TRUNC to this combination, which can only apply to a successfully opened existent file, can have no impact afaics.

Cheers,
Claudio

> > What's bugging me is that 0 and O_EXCL give the same answer, and
> > O_TRUNC and O_TRUNC | O_EXCL give the same answer,
>
> This is ok, as (iirc) O_EXCL only has effect in the presence
> of O_CREAT.

<snip more explanation>

Thanks, Claudio!

After looking at the code some more, and actually reading up on the
specs a bit more, it certainly does look like it's safe. So I don't
think we need to do anything about that.

Now, I still twist my head around the lines:
if ((fd = _open_osfhandle((long) h, fileFlags & O_APPEND)) < 0
||
(fileFlags & (O_TEXT | O_BINARY) && (_setmode(fd,
fileFlags & (O_TEXT | O_BINARY)) < 0)))

With the _setmode() call deep in the if statement... I would suggest we
split that up into a couple of lines to make it more readable - I'm sure
all compilers will easily optimise it into the same code anyway.
Reasonable?

//Magnus