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
There is a small bug in the fopen() wrapper code that was applied a
couple of weeks back for win32. It sets the wrong flags for files opened
in "append" mode. This makes the logfile writing not work - syslog.c
opens the logfile in append mode, but if the file does not already
exist, it will not be
18 matches
Mail list logo
