On 24 December 2015 at 20:23, Eli Zaretskii wrote:
>> I'm trying to read the libc manual closely and, actually, it's
>> probably not necessary:
>>
>> If all input from the input buffer is successfully converted and
>> stored in the output buffer, the function returns the number of
>>
On 26 December 2015 at 07:34, Eli Zaretskii wrote:
> Perhaps it would be better to put this in the EILSEQ part of the
> switch above. The result should be the same, AFAICT, since EILSEQ is
> the only case when we don't 'continue' or 'return', but having the
> code there makes it more self-explana
> Date: Fri, 25 Dec 2015 21:59:45 +
> From: Gavin Smith
> Cc: Texinfo
>
> On 25 December 2015 at 21:52, Gavin Smith wrote:
> >
> > That may not come out right but the point is that "\201" isn't at the
> > end, when it should be.
> >
> > I think this will be easy to fix, I'll probably do it
On 25 December 2015 at 21:52, Gavin Smith wrote:
>
> That may not come out right but the point is that "\201" isn't at the
> end, when it should be.
>
> I think this will be easy to fix, I'll probably do it today or tomorrow.
Here's the fix; I'll commit tomorrow unless a problem comes to light.
On 25 December 2015 at 14:42, Eli Zaretskii wrote:
>
> Committed.
Here's another test file demonstrating a problem. This time I put a
byte that wasn't valid in cp-1255 in the file. Because the conversion
isn't flushed before the substitute text is added, the output is out
of order. So the output
> Date: Fri, 25 Dec 2015 09:14:54 +
> From: Gavin Smith
> Cc: Texinfo
>
> On 25 December 2015 at 07:14, Eli Zaretskii wrote:
> >
> > So is the patch good to go in?
> >
>
> Yes.
Committed.
On 25 December 2015 at 07:14, Eli Zaretskii wrote:
>
> So is the patch good to go in?
>
Yes.
> Date: Thu, 24 Dec 2015 21:13:53 +
> From: Gavin Smith
> Cc: Texinfo
>
> Here's a test file that demonstrates the problem. In the second line,
> there is an extra character being viewed as part of the
> cross-reference, likely because of this problem. (Test file is in
> CP1255 and I viewed
On 23 December 2015 at 18:19, Eli Zaretskii wrote:
>> If you had any test files where characters are disappearing, it would
>> be interesting if I could see them.
>
> I have shown one case here:
>
> http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00110.html
>
> Convert the %NN URL-encoding
On 24 December 2015 at 20:23, Eli Zaretskii wrote:
> But we do: that's the other hunk in the diffs:
>
> - if (iconv_ret != (size_t) -1)
> + /* Make sure libiconv flushes out the last converted character.
> +This is required when the conversion is stateful, in which
> +cas
> Date: Thu, 24 Dec 2015 19:45:56 +
> From: Gavin Smith
> Cc: Texinfo
>
> > Here's what I came up with, please see if it looks better now.
>
> It looks okay as far as I can tell without testing it, except for this
> addition:
>
> >else
> > {
> >utf8_char_ptr =
> Here's what I came up with, please see if it looks better now.
It looks okay as far as I can tell without testing it, except for this addition:
>else
> {
>utf8_char_ptr = utf8_char;
>/* i is width of UTF-8 character */
>degrade_utf8 (&utf8_ch
> Date: Wed, 23 Dec 2015 19:15:18 +
> From: Gavin Smith
> Cc: Texinfo
>
> > /* We want to read exactly one character. Do this by
> > restricting size of output buffer. */
> > utf8_char_ptr = utf8_char;
> > for (i = 1; i <= 4; i++)
> > {
> > utf8_
On 23 December 2015 at 18:48, Eli Zaretskii wrote:
>> Date: Wed, 23 Dec 2015 20:23:41 +0200
>> From: Eli Zaretskii
>> Cc: bug-texinfo@gnu.org
>>
>> Yes, you are right, I think I should change the logic there. Will
>> resubmit.
>
> Btw, can you tell why you needed this logic:
>
> /* We want
> Date: Wed, 23 Dec 2015 20:23:41 +0200
> From: Eli Zaretskii
> Cc: bug-texinfo@gnu.org
>
> Yes, you are right, I think I should change the logic there. Will
> resubmit.
Btw, can you tell why you needed this logic:
/* We want to read exactly one character. Do this by
restrictin
> Date: Wed, 23 Dec 2015 20:19:13 +0200
> From: Eli Zaretskii
> Cc: bug-texinfo@gnu.org
>
> > > @@ -918,7 +920,13 @@ copy_converting (long n)
> > >iconv_ret = iconv (iconv_to_utf8, &inptr, &bytes_left,
> > > &utf8_char_ptr, &utf8_char_free);
> > >
> Date: Wed, 23 Dec 2015 18:03:15 +
> From: Gavin Smith
> Cc: Texinfo
>
> On 23 December 2015 at 17:38, Eli Zaretskii wrote:
> > Attached. OK to commit?
>
> Thanks. It looks mostly OK; it would be good to have a comment
> explaining why we have to call iconv a second time.
OK, I will add
On 23 December 2015 at 17:38, Eli Zaretskii wrote:
> Attached. OK to commit?
Thanks. It looks mostly OK; it would be good to have a comment
explaining why we have to call iconv a second time.
There's one part that there could be a problem with, if I understand correctly:
> @@ -918,7 +920,13 @@
> Date: Mon, 21 Dec 2015 22:24:01 +0200
> From: Eli Zaretskii
> Cc: bug-texinfo@gnu.org
>
> > Date: Mon, 21 Dec 2015 19:51:56 +
> > From: Gavin Smith
> > Cc: Texinfo
> >
> > > http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00111.html
> > > http://lists.gnu.org/archive/html/bug-w
On 21 December 2015 at 20:24, Eli Zaretskii wrote:
> No, cp1255 doesn't have it, if I understand what you are asking. The
> problem is that some cp1255 characters are combining characters, so
> libiconv composes them with the preceding character into a single
> codepoint of the corresponding prec
> Date: Mon, 21 Dec 2015 19:51:56 +
> From: Gavin Smith
> Cc: Texinfo
>
> > http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00111.html
> > http://lists.gnu.org/archive/html/bug-wget/2015-12/msg00113.html
> >
> > So I suggest we fix this in Info by adding a call to 'iconv' when the
On 21 December 2015 at 17:08, Eli Zaretskii wrote:
> I noticed that info-utils.c doesn't call 'iconv' one last time after
> the conversion is finished. This is required to output the last
> character when the conversion is implemented by libiconv as a stateful
> one.
>
> See this discussion on Wg
I noticed that info-utils.c doesn't call 'iconv' one last time after
the conversion is finished. This is required to output the last
character when the conversion is implemented by libiconv as a stateful
one.
See this discussion on Wget mailing list about one such problem:
http://lists.gnu.org
23 matches
Mail list logo
