> From: Jim Meyering <[email protected]>
> Cc: [email protected], [email protected]
> Date: Mon, 03 Oct 2011 10:17:44 +0200
>
> Eli Zaretskii wrote:
>
> >> From: Jim Meyering <[email protected]>
> >> Cc: [email protected], [email protected]
> >> Date: Sun, 02 Oct 2011 21:45:01 +0200
> >>
> >> Eli, can you confirm that this also solves the problem
> >
> > No, it doesn't. The branch of the code that calls wctob was where the
> > trouble was happening to begin with. The patch below, which still
> > goes through a temporary `unsigned char' variable, does work.
>
> Can you explain or demonstrate how wctob's "int" return
> value was inappropriately sign-extended?
I get a negative value for 0x95 from `lex'. An explicit `fprintf'
after this line:
(c) = wctob(wc);
shows that the value of `c' is -107. The value returned by wctob, if
printed using %d is -107, and if printed with %x, shows as 0xffffff95.
I would be happy to provide more details, but please tell me what do
you want to know.
> > - (c) = wctob(wc); \
> > + uc = (unsigned) wctob(wc); \
> > + (c) = uc; \
>
> If that works for you, then you must not be
> testing with anything that would set C to \xff.
>
> Using that code would truncate wctob's "int" result to "char" width,
> and thus make it impossible to distinguish between a result of 0xff and EOF.
It should be easy to test whether the return value of wctob is -1, and
only coerce the other values to unsigned char. Would that DTRT?
As I said: I'm not an expert on these issues, so perhaps I'm missing
something. If you could guide me what to try, I'm quite sure we will
find a good solution to this problem.
