Mail Archives: djgpp-workers/2001/02/15/12:18:29
> From: "Mark E." <snowball3 AT bigfoot DOT com>
> Date: Thu, 15 Feb 2001 10:45:22 -0500
>
> > > + __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.
You are right. Sorry I missed such an obvious thing.
> > 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.
Yes, but we are talking about a general-purpose feature in the
library.
> 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.
If there's some way of knowing what happens in the Win32 API calls
when the same file is open twice, we should consider emulating the
same behavior, but only if we think it's The Right Thing. This won't
be the first time DJGPP ``fixes'' DOS or Windows.
> > 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?
At least some flags to handle the mentioned cases correctly. Perhaps
also a member that will link an entry with other associated entries
(read: handles open for the same file).
> > > + 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.
Do we have to use zero-size arrays? Isn't a pointer enough? Or am I
missing something (again)?
- Raw text -