Re: RFS: swath 0.3.3-1 (updated package)
On Sat, Mar 22, 2008 at 6:49 PM, Theppitak Karoonboonyanan
> 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:
Update: It seems to require even more changes than I
> - 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.
1 more base class and 2 more derived classes are found to
require such change, totalling in 1 public function, 2 abstract
base classes, and 6 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.
Even with the GNU extension, it seems impossible to
continue using C++ iostream without causing memory leaks,
as the fstream destructor always closes the stream, and
there is no method to detach the file descriptor to prevent
such behavior. Then, a way to leave the file open (so it's not
immediately deleted) is to leave the allocated fstream objects
undeleted on return.
A better way yet is to totally replace C++ iostream with C
/me never feels disappointed with C++ like this before.
> 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?
I still think what we need for a seriously broken piece of
software is to provide the fix early, rather than develop it
that much. So, could you grant the postponement of the
gcc warning fix to next upload?
Meanwhile, I'm still working on the fix. But as the changes
grow, I feel more needs of testing before actually releasing.