Re: Bad bug in fopen() wrapper code

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Claudio Natoli" <claudio(dot)natoli(at)memetrics(dot)com>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Bad bug in fopen() wrapper code
Date: 2006-09-27 07:47:21
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA0FBED@algol.sollentuna.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

> > 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2006-09-27 08:17:52 Re: Block B-Tree concept
Previous Message Zdenek Kotala 2006-09-27 07:31:28 Re: horo(r)logy test fail on solaris (again and solved)

Browse pgsql-patches by date

  From Date Subject
Next Message Jeremy Drake 2006-09-27 08:57:28 large object regression tests, take two
Previous Message Tom Lane 2006-09-27 02:25:48 Re: Faster StrNCpy