I got a private email from Claudio saying he already answered this
question:
http://archives.postgresql.org/pgsql-patches/2006-09/msg00285.php
I forgot I saw it, so I have added comments to the C code.
---
bruce wr
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > That is part of the original open() code that Claudio did back for 8.0,
> > so it has definitly been working since then.
>
> Hm, maybe best not to touch it, but still...
>
> > I haven't really read into
> > the code, though... Bu
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
> > > > >>
> > > > 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
"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes:
> "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 ?
I think the usual convention is to test for < 0, unless there are other
negat
> 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 suppose
> > > > > 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
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)))
>
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
"Magnus Hagander" <[EMAIL PROTECTED]> 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 mysel
> >> 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
"Claudio Natoli" <[EMAIL PROTECTED]> writes:
> 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)))
> Without h
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 th
> > 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.
Thanks, Claudio!
After looking at the code some more, and actually reading up on the
spec
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 l
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> This is pretty bad and pretty urgent - with this, systems installed by
> the MSI installer simply *do not start*, because they are by default
> configured to write logs to a file...
> Attached patch sets the O_CREAT option when appending to files.
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> That is part of the original open() code that Claudio did back for 8.0,
> so it has definitly been working since then.
Hm, maybe best not to touch it, but still...
> I haven't really read into
> the code, though... But a qiuck look doesn't show me a
> > Attached patch sets the O_CREAT option when appending to files.
>
> That looks correct, but I went looking to see if there were
> any other mistakes of the same ilk, and I'm wondering what
> the sense is in openFlagsToCreateFileFlags ... seems like
> it's ignoring O_EXCL in some combinatio
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Attached patch sets the O_CREAT option when appending to files.
That looks correct, but I went looking to see if there were any other
mistakes of the same ilk, and I'm wondering what the sense is in
openFlagsToCreateFileFlags ... seems like it's ign
19 matches
Mail list logo
