Re: gsf api thoughts

On Thu, 2002-08-01 at 22:47:28, Jody Goldberg wrote:

> (...)
> 1) gsf_output_printf (and friends)
> On the input side I got a gsf_input_textline class to handle reading
> text sources line by line (1 byte encoding or utf8).  That seems

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')

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.

> 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).


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