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]