[GRASS5] Re: V_ stuff

[Glynn Clements]

Huidae Cho wrote:

> > > > Huidae; do you want to deal with this, or shall I? For now, I'll leave
> > > > it alone unless told otherwise.
> > > 
> > > I don't know the side effects of this ASIAN_CHARS fix exactly. It's
> > > just test code because I didn't see where >128 char is used for now.
> > > 
> > > So it would be nice to leave it untouched until this fix turns out ok.
> >
> > Are you satisfied with it yet?
> >
> > We are approaching release, so this needs to be fixed soon.
> 
> Hmm, are you lost my update?
> I've already implemented ./configure flag, --with-asian-chars,
> to switch on multiple-byte characters.  I named this flag as
> --with-asian-chars because i'm not sure if this flag works for all
> multiple-byte characters.

I wasn't aware that this had anything to do with multi-byte
characters; I thought that it was just 8-bit characters. Looking at
the code (i.e. all occurrences of "ASIAN_CHARS") indictates that it
*is* just 8-bit characters.

Currently, you have a choice of bugs, depending upon whether the
ASIAN_CHARS macro is defined.

1. If ASIAN_CHARS is not defined, then there are several places where
an 8-bit character is silently "coerced" into the 7-bit range by
ANDing with 0177 (0x7F).

If GRASS can't cope with 8-bit characters, they should be ignored, or
an error generated, or translated to a specific character (e.g. '?'). 
They definitely shouldn't be converted to some arbitrary unrelated
character.

2. If ASIAN_CHARS is defined, then there are several places where a
"less than zero" test is used on a "char". This assumes that "char" is
signed, which isn't guaranteed by ANSI C.

If you want to perform comparisons on 8-bit characters, you *cannot*
use "char"; you *must* explicitly specify "signed char" or "unsigned
char".

Basically I'm trying to determine whether both cases need to be fixed,
or if one of the cases can be scrapped. The only reason for having
both is if the 8-bit version is too unreliable for general use but
still useful as an option.

> It would be great if you test this flag for your multiple-byte characters.
> Then please inform me if this works correctly.

The only reliable testing will come from people who actually make real
use of GRASS. I'm not one of them; I'm a computer programmer, not a
geographer, cartographer or similar. And even if I was, as a native
English speaker I don't normally use non-ASCII characters (other than
the occasional pound (sterling) sign).

Personally I would prefer it if vasklib at least was 8-bit clean. The
only way in which we will discover bugs in the handling of 8-bit
characters in individual programs is if users have some means of
entering them.

For this reason, I would suggest that the conditionals be removed,
with the 8-bit (ASIAN_CHARS) case remaining. The old code simply
masked any problems (and didn't do a particularly good job at that). 
In the absence of anyone giving reasons to the contrary, I'll get onto
this.

BTW, I've also spotted a couple of other problems in vasklib which
need fixing (e.g. assigning the result of wgetch() to a "char"
variable). While I'm at it, I may as well look into fixing the
handling of extended keys.

PS: Anyone interested in portability testing might consider adding
"-funsigned-char" to their CFLAGS.

-- 
Glynn Clements <glynn.clements at virgin.net>