From: SourceForge.net <no...@so...> - 2004-10-17 19:32:50
|
Bugs item #1048593, was opened at 2004-10-17 10:35 Message generated for change (Comment added) made by brandysb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1048593&group_id=2435 Category: mingw runtime Group: Feature requests Status: Open Resolution: None Priority: 5 Submitted By: Boguslaw (brandysb) Assigned to: Nobody/Anonymous (nobody) Summary: tmpfile() replacement Initial Comment: MAX_TMP 32767 Bug report (Closed) for mingw-runtime no. 1047975 If tmpfile() limitation to 32767 temporary files in process and this is related to MSVC runtime please consider replacement for this function. This could be simple, fast and efficient like this : FILE * tmpfile(void) { char filename[MAX_PATH]; FILE *f; GetTempFileName(".","temp",0,filename); f = fopen(filename,"w+bTD"); return f; } Works very well. Best Regards Bogusław Brandys ---------------------------------------------------------------------- >Comment By: Boguslaw (brandysb) Date: 2004-10-17 21:32 Message: Logged In: YES user_id=1092450 Modified proposition: FILE * tmpfile(void) { char temppath[MAX_PATH]; char filename[MAX_PATH]; FILE *f; int i; i = GetTempPath(MAX_PATH,temppath); if ((i==0) || (i > MAX_PATH)) return NULL; if (GetTempFileName(temppath,"tmp",0,filename)==0) return NULL; f = fopen(filename,"w+bTD"); return f; } Regarding MSDN documentation tmpfile() VC++ implementation is far from complete. I didn't find any errno setting mentioned in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt_tmpfile.asp - only NULL is returned in case of error. I'm not going to send a "ready to go" implementation (in that case I should then rather send a patch) but my example is really based on two functions , and I think that both are very known. I tested race conditions and seems no one exists even if the same prefix for temporary files is given . Someone could extend this function to set always unique prefix based on rand or time value but it seems not necessary becouse GetTempFileName is internally checking for file presence. If somebody could check permissions behaviour I would be glad also. i checked it only on read-only system and just return NULL (proper behaviour) Option T means _O_SHORTLIVED and could be removed in case of security (file is maintained fully in memory if available) Check also http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/gettempfilename.asp Regards Boguslaw Brandys ---------------------------------------------------------------------- Comment By: Aaron W. LaFramboise (aaronwl) Date: 2004-10-17 20:28 Message: Logged In: YES user_id=1040098 I'd say that "simple, fast, and efficient" is something of a myth in generic library code that must cope with diverse situations that its creator may not have foreseen. There are a few problems here: The return values for both functions need to be checked, as both of them can fail. Sometimes this can mean a security problem (some versions of mkstemp() will warn about this situation), but on Windows, as far as I know all versions that enforce user permissions also give each user a different temp dir. I could still see potiential for abuse coming from two programs running as the same user being manipulated in some way by an adversary. "." maybe should be GetTempPath(). I noticed that msvcrt tmpfile() just creates the files in c:\, which is a little odd. Some parts of the documentation imply that it might create files in the pwd. It seems best to use TEMP or TMP though, as GetTempPath() does. This implementation isn't actually standards-conforming, because it doesn't remove the files automatically on close or on program termination (the standard permits either). However, MSVC docs are more strict, stating that the file is removed on close. I beleive this can be accomplished by manipulating the iobuf directly to save the filename. _rmtmp() compatibility with the new tmpfile() would also need to be confirmed. msvc probably also is passing _O_TEMPORARY to _open(), which might cause it to pass FILE_ATTRIBUTE_TEMPORARY to CreateFile(). This is impossible to do through fopen(). The situation here needs to be investigated. Multithreading needs to be examined. This function will probably need to lock a mutex: the gap between fopen() and setting iobuf attributes might cause problems for certain functions, such as _rmtmp(). There might be other things. This is just what popped into my head. In any case, any replacing of a function needs to be thought about very carefully. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1048593&group_id=2435 |