octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 8-bit char problem


From: Paul Kienzle
Subject: Re: 8-bit char problem
Date: Fri, 11 Oct 2002 10:58:05 -0400

On Thu, Oct 10, 2002 at 04:29:19PM -0500, John W. Eaton wrote:
> On 10-Oct-2002, Paul Kienzle <address@hidden> wrote:
> 
> | Under mingw and cygwin, toascii(setstr(200)) == 72 and
> | toascii(setstr(-100)) == 28.  It seems we only have 7-bit 
> | characters to work with.
> 
> FWIW, this is also what happens on my Debian system:
> 
>   bevo:386> octave
>   GNU Octave, version 2.1.36 (i386-pc-linux-gnu).
>   Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2002 John W. Eaton.
>   This is free software; see the source code for copying conditions.
>   There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
>   FITNESS FOR A PARTICULAR PURPOSE.  For details, type `warranty'.
> 
>   Report bugs to <address@hidden>.
> 
>   octave:1> toascii(setstr(200)) 
>   ans = 72
>   octave:2> toascii(setstr(-100)) 
>   ans = 28

Mine too :-(  From the toascii man page, I see that it is supposed to strip
the top bit.  I did some more tests of the problem I'm trying to solve
(colormaps on my images are messed up on Windows), and setstr is not the
cause.

Perhaps I will write a function double() to convert from characters to
unsigned(?) numbers, but I don't need it for now.

> 
> | I'm recompiling with -funsigned-char to see if I can get
> | toascii(setstr(200)) == 200, but the proper solution is 
> | to tag all chars with unsigned.
> 
> This could be somewhat painful, but I suppose it might be worth doing
> it.

Yes it will be painful because the system string functions and the
consumers of charMatrix use char, and we don't want to replace them all, so
casts will be sprinkled everywhere.  I'm inclined to ignore it for now.

I wonder how much more work it would be to support unicode?

Paul Kienzle
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]