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.
