Unix Technical Forum

Re: Bad bug in fopen() wrapper code

This is a discussion on Re: Bad bug in fopen() wrapper code within the Pgsql Patches forums, part of the PostgreSQL category; --> Magnus Hagander writes: > Now, I still twist my head around the lines: > if ((fd = _open_osfhandle((long) h, ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Patches

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-18-2008, 10:02 AM
Claudio Natoli
 
Posts: n/a
Default Re: Bad bug in fopen() wrapper code


Magnus Hagander writes:
> 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?


I agree it would be clearer if split up.

Without having studied it closely, it might also highlight a bug on failure of the second clause -- if the _setmode fails, shouldn't _close be called instead of CloseHandle, and -1 returned? (CloseHandle would still be called on failure of the _open_osfhandle, obviously)

Cheers,
Claudio

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-18-2008, 10:02 AM
Magnus Hagander
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

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

>
> > Without having studied it closely, it might also highlight a bug

> on
> > failure of the second clause -- if the _setmode fails, shouldn't
> > _close be called instead of CloseHandle, and -1 returned?
> > (CloseHandle would still be called on failure of the

> _open_osfhandle,
> > obviously)

>
> I agree that this code is both wrong and unreadable (although in
> practice the _setmode will probably never fail, which is why our
> attention hasn't been drawn to it). Is someone going to submit a
> patch? I'm hesitant to change the code myself since I'm not in a
> position to test it.


I can look at fixing that. Is it something we want to do for 8.2, or
wait until 8.3? If there's a hidden bug, I guess 8.2?

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-18-2008, 10:02 AM
Tom Lane
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

"Magnus Hagander" <mha@sollentuna.net> writes:
>> I agree that this code is both wrong and unreadable (although in
>> practice the _setmode will probably never fail, which is why our
>> attention hasn't been drawn to it). Is someone going to submit a
>> patch? I'm hesitant to change the code myself since I'm not in a
>> position to test it.


> I can look at fixing that. Is it something we want to do for 8.2, or
> wait until 8.3? If there's a hidden bug, I guess 8.2?


Yeah, I think it's 8.2 material.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #4 (permalink)  
Old 04-18-2008, 10:03 AM
Bruce Momjian
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

Magnus Hagander wrote:
> > >> 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)))

> >
> > > Without having studied it closely, it might also highlight a bug

> > on
> > > failure of the second clause -- if the _setmode fails, shouldn't
> > > _close be called instead of CloseHandle, and -1 returned?
> > > (CloseHandle would still be called on failure of the

> > _open_osfhandle,
> > > obviously)

> >
> > I agree that this code is both wrong and unreadable (although in
> > practice the _setmode will probably never fail, which is why our
> > attention hasn't been drawn to it). Is someone going to submit a
> > patch? I'm hesitant to change the code myself since I'm not in a
> > position to test it.

>
> I can look at fixing that. Is it something we want to do for 8.2, or
> wait until 8.3? If there's a hidden bug, I guess 8.2?


Magnus, is this the right fix?

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #5 (permalink)  
Old 04-18-2008, 10:03 AM
Bruce Momjian
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

Bruce Momjian wrote:
> Magnus Hagander wrote:
> > > >> 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)))
> > >
> > > > Without having studied it closely, it might also highlight a bug
> > > on
> > > > failure of the second clause -- if the _setmode fails, shouldn't
> > > > _close be called instead of CloseHandle, and -1 returned?
> > > > (CloseHandle would still be called on failure of the
> > > _open_osfhandle,
> > > > obviously)
> > >
> > > I agree that this code is both wrong and unreadable (although in
> > > practice the _setmode will probably never fail, which is why our
> > > attention hasn't been drawn to it). Is someone going to submit a
> > > patch? I'm hesitant to change the code myself since I'm not in a
> > > position to test it.

> >
> > I can look at fixing that. Is it something we want to do for 8.2, or
> > wait until 8.3? If there's a hidden bug, I guess 8.2?

>
> Magnus, is this the right fix?


Claudio sent me some small updates to the patch; updated version
attached.

--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #6 (permalink)  
Old 04-18-2008, 10:03 AM
Magnus Hagander
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

> > > > > Without having studied it closely, it might also
> highlight a bug
> > > > on
> > > > > failure of the second clause -- if the _setmode

> fails, shouldn't
> > > > > _close be called instead of CloseHandle, and -1 returned?
> > > > > (CloseHandle would still be called on failure of the
> > > > _open_osfhandle,
> > > > > obviously)
> > > >
> > > > I agree that this code is both wrong and unreadable

> (although in
> > > > practice the _setmode will probably never fail, which

> is why our
> > > > attention hasn't been drawn to it). Is someone going

> to submit a
> > > > patch? I'm hesitant to change the code myself since

> I'm not in a
> > > > position to test it.
> > >
> > > I can look at fixing that. Is it something we want to do

> for 8.2, or
> > > wait until 8.3? If there's a hidden bug, I guess 8.2?

> >
> > Magnus, is this the right fix?

>
> Claudio sent me some small updates to the patch; updated
> version attached.


If we're going for maximum readability, I'd actually split
+ else if (fileFlags & (O_TEXT | O_BINARY) &&
+ _setmode(fd, fileFlags & (O_TEXT | O_BINARY)) < 0)

into two different if statements as wlel. Ee.g.
else if (fileFlags (O_TEXT | O_BINARY)) {
if (_setmode() < 0) {
failure();
}
}


Haven't tested the patch yet, but it looks ok.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #7 (permalink)  
Old 04-18-2008, 10:03 AM
Zeugswetter Andreas DCP SD
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code


> Magnus, is this the right fix?


Well, actually msdn states:

"Return Value
If successful, _setmode returns the previous translation mode. A return
value of -1 indicates an error"

So, shouldn't we be testing for -1 instead of < 0 ?

The thing is probably academic, since _setmode is only supposed to fail
on invalid file handle or invalid mode.
So basically, given our code, it should only fail if filemode is
(O_BINARY | O_TEXT) both flags set.

Andreas

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #8 (permalink)  
Old 04-18-2008, 10:03 AM
Magnus Hagander
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code

> > > > I agree that this code is both wrong and unreadable
> (although in
> > > > practice the _setmode will probably never fail, which

> is why our
> > > > attention hasn't been drawn to it). Is someone going

> to submit a
> > > > patch? I'm hesitant to change the code myself since

> I'm not in a
> > > > position to test it.
> > >
> > > I can look at fixing that. Is it something we want to do

> for 8.2, or
> > > wait until 8.3? If there's a hidden bug, I guess 8.2?

> >
> > Magnus, is this the right fix?

>
> Claudio sent me some small updates to the patch; updated
> version attached.


Tested, passes all regression tests on MingW.

//Magnus

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #9 (permalink)  
Old 04-18-2008, 10:03 AM
Bruce Momjian
 
Posts: n/a
Default Re: [HACKERS] Bad bug in fopen() wrapper code


Applied.

---------------------------------------------------------------------------

Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Magnus Hagander wrote:
> > > > >> 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)))
> > > >
> > > > > Without having studied it closely, it might also highlight a bug
> > > > on
> > > > > failure of the second clause -- if the _setmode fails, shouldn't
> > > > > _close be called instead of CloseHandle, and -1 returned?
> > > > > (CloseHandle would still be called on failure of the
> > > > _open_osfhandle,
> > > > > obviously)
> > > >
> > > > I agree that this code is both wrong and unreadable (although in
> > > > practice the _setmode will probably never fail, which is why our
> > > > attention hasn't been drawn to it). Is someone going to submit a
> > > > patch? I'm hesitant to change the code myself since I'm not in a
> > > > position to test it.
> > >
> > > I can look at fixing that. Is it something we want to do for 8.2, or
> > > wait until 8.3? If there's a hidden bug, I guess 8.2?

> >
> > Magnus, is this the right fix?

>
> Claudio sent me some small updates to the patch; updated version
> attached.
>
> --
> Bruce Momjian bruce@momjian.us
> EnterpriseDB http://www.enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +


[ text/x-diff is unsupported, treating like TEXT/PLAIN ]

> Index: src/port/open.c
> ================================================== =================
> RCS file: /cvsroot/pgsql/src/port/open.c,v
> retrieving revision 1.15
> diff -c -c -r1.15 open.c
> *** src/port/open.c 24 Sep 2006 17:19:53 -0000 1.15
> --- src/port/open.c 3 Oct 2006 01:16:43 -0000
> ***************
> *** 105,113 ****
> }
>
> /* _open_osfhandle will, on error, set errno accordingly */
> ! if ((fd = _open_osfhandle((long) h, fileFlags & O_APPEND)) < 0 ||
> ! (fileFlags & (O_TEXT | O_BINARY) && (_setmode(fd, fileFlags & (O_TEXT | O_BINARY)) < 0)))
> CloseHandle(h); /* will not affect errno */
> return fd;
> }
>
> --- 105,119 ----
> }
>
> /* _open_osfhandle will, on error, set errno accordingly */
> ! if ((fd = _open_osfhandle((long) h, fileFlags & O_APPEND)) < 0)
> CloseHandle(h); /* will not affect errno */
> + else if (fileFlags & (O_TEXT | O_BINARY) &&
> + _setmode(fd, fileFlags & (O_TEXT | O_BINARY)) < 0)
> + {
> + _close(fd);
> + return -1;
> + }
> +
> return fd;
> }
>


--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:15 PM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
SEO by vBSEO 3.2.0
www.UnixAdminTalk.com