Mail Archives: djgpp-workers/2001/02/15/10:53:23
> Are there any other platforms which support this functionality? How
> do these platforms document the behavior of this flag? Where (in what
> situations) is this feature useful?
1) None that I'm aware of. 2) N/A. 3) For programs that use the Unixy
open/remove feature like Bash. Perl uses O_TEMPORARY.
>
> Also, by ``Mingw32'' do you mean to say that this feature is supported
> by MSVCRT.DLL (or whatever the C run-time support is called)?
Yes.
> > + __o_temporary_files[to] = __o_temporary_files[from];
> > + ++(__o_temporary_files[to]->ref_count);
> > + }
> > + }
>
> I think this is wrong. After a call to `dup', you have one file open
> on two different handles. The above code leaves the ref_count of the
> old handle at 1, and sets the ref_count of the new handle to 2. This
> means that if I close the old handle, the file will be deleted that
> very moment--probably not what you want.
I think I'm right. The first line of code above has both 'to' and 'from'
point at the same structure. The next line then increments the ref_count
pointed at by both handles. Therefore it must be true that
__o_temporary_files[to]->ref_count == __o_temporary_files[from]->ref_count.
> Similar problems will happen with the same file open more than once
> with the O_TEMPORARY attribute:
> Another aspect that I think needs to be considered is the situation
> where the same file is opened once with O_TEMPORARY, and then again
> without O_TEMPORARY.
At least with Bash, these two problems wouldn't occur since it just replaces
the workaround for the open/remove code.
I haven't tried O_TEMPORARY under Win32 so I can't say what happens there
yet. But I would imagine it just sets a flag for the call to CreateFile and
does nothing more.
> I think these considerations suggest that the data structure you use
> to hold the information should be redesigned, to avoid these kinds of
> lossage, and the code changed accordingly.
Perhaps I'm too close to be objective, but I don't what changes to the
structure are to be made. What changes do you suggest?
> > + typedef struct
> > + {
> > + unsigned char ref_count __attribute__((packed));
> > + char filename[0] __attribute__((packed));
> > + } o_temporary_file_rec;
>
> Why did you pack the struct? Wouldn't it be better to reverse the
> order of the struct members and leave out the packed attribute?
Because zero size arrays must be the last member of a struct according to
gcc's documentation on zero size arrays.
Mark
- Raw text -