[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: swath 0.3.3-1 (updated package)

On Sat, Mar 22, 2008 at 4:38 PM, Theppitak Karoonboonyanan
<thep@linux.thai.net> wrote:
> On Sat, 22 Mar 2008 15:37:38 +0900, Paul Wise <pabs@debian.org> 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?

Theppitak Karoonboonyanan

Reply to: