Mail Archives: djgpp-workers/2001/03/02/05:43:19
> From: "Mark E." <snowball3 AT bigfoot DOT com>
> Date: Thu, 1 Mar 2001 15:40:06 -0500
>
> > > ! {
> > > ! fd = _creat(real_name, dmode);
> > > ! if (fd != -1)
> > > ! __set_fd_properties(fd, real_name, oflag);
>
> > This is okay, but it means that an application cannot open an
> > O_TEMPORARY file via _open or _creatnew. Is that what we want?
>
> Did you mean via _creat?
No, I meant _creatnew, although _creat should probably also call
__set_fd_properties if it doesn't.
> I do have a call to __set_fd_properties in _open.
I don't have all the diffs handy here, but IIRC, _creatnew only passed
O_BINARY to __set_fd_properties, and _open did similar things.
> I can add a call to __set.... in _creat, but I don't see how
> O_TEMPORARY can be passed to _creat when it doesn't take accept O_*
> flags.
Since O_TEMPORARY is beyond the low 16 bits, an application can pass
it to _open without fear.
The real issue here is this: do we want to record as many handles as
possible in __fd_properties, to avoid adverse effects on code that
uses e.g. _open and open interspersely? If we do, we should push
__set_fd_properties to the lowest possible level; if we don't, we
should document that handles open by _open, _creat and _creatnew might
not DTRT in conjunction with O_TEMPORARY.
- Raw text -