From: Jody Goldberg (jody@gnome.org)
Date: Fri Aug 02 2002 - 09:29:20 EDT
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.
This archive was generated by hypermail 2.1.4 : Fri Aug 02 2002 - 09:36:34 EDT