Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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

pgsql-hackers by date

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

pgsql-patches by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group