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?
Regards,
--
Theppitak Karoonboonyanan
http://linux.thai.net/~thep/
Reply to: