Re: gsf api thoughts



On Fri, Aug 02, 2002 at 02:14:56PM +0200, Zbigniew Chyla wrote:
I have no opinions on this but while reading gsf sources I noticed that
the only difference between gsf_input_textline_ascii_gets and
gsf_input_textline_utf8_gets is:

@@ -21,7 +21,7 @@ gsf_input_textline_ascii_gets (GsfInputT
 
                ptr = textline->remainder;
                end = ptr + textline->remainder_size;
-               for (; ptr < end ; ptr++)
+               for (; ptr < end ; ptr = g_utf8_next_char (ptr))
                        if (*ptr == '\n' || *ptr == '\r')
                                break;

All 7-bit characters (including '\n' and '\r') can represent only
themselves in UTF-8 strings (every byte in multibyte sequence has the
highest bit set to 1) so it looks like both functions do he same thing.
I suggest removing gsf_input_textline_utf8_gets.

This is because utf8_gets has not been written yet :-)

I'd like the gets methods to offer a guarantee that the content
coming back is valid.  Admitedly there is a potential to merge the
various gets methods into one, and set an 'encoding' flag on the
stream.  I have no strong preferences.
 
2) output unref vs close.  Should unrefing an output close it ?
I suspect so given that any other behaviour would be much harder to
implement.
You should never rely on unref being called. What if a reference gets passed
to some garbage collector (eg Python's)? Most GCs don't guarantee that all
unused references will be freed.
I'd rather put something like:
g_assert (gsf_output_is_closed (output))
in finalize method to detect programmers' errors (the death conditon).

- g_assert from a recoverable condition in a library is not a nice
   idea.  An assertion failure looks no different from a crash to a
   user.

- This is a good reason to keep the current seperation between close
  and unref.  The Output::finalize method should warn about unclosed
  and derived finalizes can _try_ (if it looks safe) to close if
  necessary.



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