[GRASS5] Re: V_ stuff

[Huidae Cho]

From: Glynn Clements <glynn.clements at virgin.net>
> 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").
>

Hi all,

Glynn, you're right. So I added '#ifdef ASIAN_CHARS' to input an exceptional
characters such as asian chars. It does not affect any behaviour without
DASIAN_CHARS in head.$(ARCH).
For this, I didn't change var types of "newchar" and etc.

> 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.

Yours,
Huidae Cho

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