On Sat, Mar 22, 2008 at 4:38 PM, Theppitak Karoonboonyanan <[EMAIL PROTECTED]> wrote: > On Sat, 22 Mar 2008 15:37:38 +0900, Paul Wise <[EMAIL PROTECTED]> wrote: > > > Please fix this GCC warning, after that I will upload: > > > > /tmp/buildd/swath-0.3.3/src/wordseg.cpp:244: warning: the use of > > `tmpnam' is dangerous, better use `mkstemp' > > This may be better done by a new upstream release. > > In fact, using mkstemp() instead of tmpnam() means quite substantial > change to the program logic, because the temp files are actually > created deep in different functions in different branches, using > the generated temp names from a single place. Changing that behavior > would mean internal API changes. > > I will come up with a new upstream version soon, then.
Err.. I'm not sure if it's appropriate to introduce a big change just to get a serious bug fix delivered. I'm afraid it would risk introducing new bugs working in hurry as well. Here are summarized changes to be done: - mkstemp(), or better yet, tmpfile(), creates the temp file immediately and removes it as soon as it's closed, while current APIs accept file name arguments, create the files for working on and close them when done. Then, another stage opens the files again for working, using the file names arguments, and so on. So, all involved API's must be modified to accept FILE* or file descriptors instead of file names, and their implementations must not close the files when finished, or the files will be deleted and become unavailable for later stages. This involves changing 1 public function, 1 abstract base class and 4 derived classes. - The standard C++ iostream library now doesn't support using fstream with FILE* or file descriptor. (It can only open files with file names.) So, the current code cannot use the file handle or file descriptor returned from tmpfile() or mkstemp() directly without using GNU extension. This may introduce another portability issue, and some configure scripts to check this may be required. With the amount of changes involved, I'm afraid it would take too long for an urgent bug fix, and it would risk introducing new bugs as well. Could we deliver the fix first, and address the issue in next upstream version? Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
