Re: g_io_channel_read_chars() loop
- From: Ron Steinke <rsteinke w-link net>
- To: jlbec evilplan org, rsteinke w-link net
- Cc: jlbec evilplan org, gtk-devel-list gnome org
- Subject: Re: g_io_channel_read_chars() loop
- Date: Fri, 10 Aug 2001 08:06:05 -0700
> From: Joel Becker <jlbec evilplan org>
>
> On Thu, Aug 09, 2001 at 06:47:07PM -0700, Ron Steinke wrote:
> > Are you sure it's looping in g_utf8_next_char () due to the garbage?
> > That's just a macro, so at the very least it should be returning to
> > g_io_channel_read_chars () and looping there. Unless some of the
> > skips are zero, it should always increment nextchar by something.
> > Maybe the loop is somewhere else in the iochannel code?
>
> No, I didn't mean that it is looping in g_utf8_next_char() --
> that simply expands to pointer arithmetic. I just noticed that it skips
> a '\0' character, which I thought weird. I've chatted with Owen about
> it, and it is the defined behavior. In the end, it doesn't affect the
> bounds of this problem. The code is looping in the do{}while() loop
> there because got_bytes > 0 but encoded_read_buf->str[0] == '\0' (which
> should not happen at all).
You're actually allowed to have intermediate nulls in the buffer
if there are nulls in the file. If that were to happen, the
rest of the buffer would still contain valid UTF-8, but
since it's looping endlessly that obviously isn't the case.
The difficult part is that the bug is almost certainly in some
completely different part of the code. Any test case, or even
a copy of the file you're trying to read when you get the bug,
would be very helpful.
Ron
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]