From: "Mark E." To: djgpp-workers AT delorie DOT com, eli Zaretskii Date: Thu, 15 Feb 2001 10:45:22 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: O_TEMPORARY Message-ID: <3A8BB342.6283.2F2411@localhost> References: <3A8A98EE DOT 30071 DOT A8D978 AT localhost> In-reply-to: X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com > 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