[GRASS5] Re: V_ stuff

[Glynn Clements]

Markus Neteler wrote:

> below is a thread on asian characters support in GRASS which
> will become feasible with a small change proposed by Artemis.
> Huidae Cho has already implemented related improvements into
> v.digit etc. It seems that the fix would help various people
> so we should include it.
> 
> Read on below for details. Huidae, in case of no objections by
> the others, could you update this in CVS?

> [...]
> > > There's something you should know about Vask.
> > >
> > > V_support.c should have:
> > >
> > > 	in line 51 the substring:
> > > 		&& (*ANS_PTR < '\177') *
> > > 	should be deleted.
> > >
> > > V_call.c:
> > >
> > > 	in line 254:
> > > 		& 0177
> > > 	should be deleted.
> > >
> > > 	in line 410:
> > > 		&& (newchar < '\176')
> > > 	should be deleted.

> > Yes, actually it helps one type asian characters. So I updated v.digit in
> > this way and added DASIAN_CHARS into head.in some months ago.
> > 
> > If others are ok, what about adding --with-asian-chars to configure.in.
> > Without this flag, i have to add DASIAN_CHARS to head.* by hand after
> > configure.

I don't see any point in making this optional; if GRASS copes with
8-bit characters, then it may as well be unconditional.

Presumably this applies to all non-ASCII character sets, not just
Asian ones (many people would assume that ASIAN_CHARS refers to
multi-byte encodings such as ISO-2022).

BTW, I noticed this in V_call.c:

	c = getch() & 0177;

This is the wrong thing to do, for several reasons:

1. As EOF is usually -1, the "&" is going to convert it to \177, so
the "if(c == EOF)" test on the following line will fail.

2. If someone enters a top-bit-set character, and GRASS can't cope
with them, the correct solution is to reject it, not to silently
convert it to some completely unrelated character.

3. GRASS *ought* to be able to cope with it. If there are bugs related
to char signed-ness, let's fix them rather than introducing a
workaround which ensures that they'll never be found.

Also, "newchar" should probably be an "int"; this avoids the issue of
top-bit-set characters being negative. "int" variables are also likely
to be more efficient than "char" (or, for that matter, "short").

Huidae; do you want to deal with this, or shall I? For now, I'll leave
it alone unless told otherwise.

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

---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'