From: SourceForge.net <no...@so...> - 2004-10-17 18:28:09
|
Bugs item #1048593, was opened at 2004-10-17 03:35 Message generated for change (Comment added) made by aaronwl 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: Aaron W. LaFramboise (aaronwl) Date: 2004-10-17 13: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 |