Path: titcca!srava!kameyama
From: kameyama@srava.sra.JUNET (Toyohisa Kameyama)
Newsgroups: fj.kanji,fj.unix
Subject: debugger (Re: long char) (In KANJI)
Message-ID: < 881@srava.sra.JUNET> 
Date: 21 Aug 87 10:46:07 GMT
References:  < 856@srava.sra.JUNET>  < 518@cskvax.csk.JUNET> 
Reply-To: kameyama@srava.UUCP (Toyohisa Kameyama)
Distribution: fj
Organization: Software Research Associates, Inc., Japan
Lines: 90
Xref: titcca fj.kanji:204 fj.unix:169

亀山です.
In article < 518@cskvax.csk.JUNET>  shige@cskvax.csk.JUNET (Shigeki Yoshida) writes:
> article < 856@srava.sra.JUNET>  で
>  	kameyama@srava.UUCP (亀山豊久) さんが
>  > 4. CSK の JNIX (内部 16 形式)
>  >     処理コードの type
>  > 	typedef unsigned short int kanzi;
>                                        ^
>  	typedef unsigned short int kanji; です。
>  
どうもすみませんでした.
普段訓令式で書いているので手がすべったようです.

>  > 内部コードというとアルファベットの場合は ASCII と EBCDIC が代表的でしょう.
>  > それから考えると, 文字定数, 文字列定数および ``ctype''
>  > みたいな内部コードを意識しないですむ仕掛けが使えればいいのかも知れません.
>  > (しかし, ``ctype'' のような関数 (文字種の判定, 変換) がどれくらいあれば
>  > いいのだろうか?)
>  
>    ここで亀山さんが言っているのは、プログラム内部で漢字を直接扱う
>  時の問題ですね。つまり、日本語を意識することなく扱う為に必要な処理
>  として、
>  
>  	１）プログラムへの漢字（データー）の入出力
>  	２）プログラム内部での漢字データーの扱い
>  
>  があるという事です。今までは主に１）の事を問題にしてきた訳ですが、
>  ここで２）のような事も、実際のプログラミングをする上では必要と
>  思われます。
私としては最初から 2) を実現するために 1) を問題にしてきたつもりでした.

>  
>    ただ、２）を実現するにはｃｃ（またはｃｐｐ）に手を加える必要が出て
>  きますが、可能ならばそうしたほうがいいと思います。文字定数, 文字列定数
>  に直接漢字が使えるだけでもかなり違いますからね。
>  
>    実際には、ｃｃをいじくる事になると、パブリックドメインのｃコンパイ
>  ラーがいりますね。しかも、各漢字コードに対応したものを作る必要があり
>  ます。（統一した内部コードを使うにしろ、上のように使うならば、ソース
>  コードの時点ではどれかの漢字コードで書いてある訳ですからね）
>  
プリ・プロセッサで行なうという方法もあります.
文字定数は
>  	if (char > = '亜'l) {	/* JIS 1st or 2nd kanji */
	(   ~~~~ これは予約語!)
を
>  	if (char > = 0xc0a1) {	/* JIS 1st or 2nd kanji */
のように変換してしまうことは簡単にできます.
(日本語 UNIX 諮問委員会 内部コード EUC のとき)
問題は文字列のときですが, ファイルの初めのほうで,
	static short __long_string1[] = { '漢'l, '字'l, '混'l,
		'じ'l, 'り'l, 'の'l, 's', 't', 'r', 'i', 'n', 'g', '\0'};
(実際には漢字の部分は整数に直す必要がある.)
という行を挿入し, 文字列があったところは,
	pointer = __long_string1;
というようにすればよいはずでえす.
原理的にはこんなものですが実現するためには変数の名前をどうするかという
問題があります.

ところで, 内部コードを file コードと違うものを使用するとき,
大きな問題があるのを忘れていました.
それは,
debugger の問題です.

dbx では普通の文字列は (日本語が含まれていても) きちんと文字列を出力して
くれます.
しかし, 内部コードでたとえば unsigned short を使用すると文字列は
整数配列もしくはポインタになるので, 整数の列かアドレスしか
出力されません.
そのため, debug は困難になります.

この問題は内部コードにファイルコード以外のものを使用するときだけでなく,
一般に基本データ型以外のデータ構造を使用するときに問題になります.

たとえば, text formatter を作ったとき, long に
文字コード, フォント, サイズなどを詰め込んだ場合,
debugger の中でそれがどんな文字かを汁のは不可能に近いでしょう.
構造体にしたとしたら, その文字はわかりますが,
その辺の内容を文字列として把握するのは困難でしょう.

自分で定義したデータ構造を自分で定義した出力形式 (文字列, 図形を含む)
で出力できるような debugger はどこかにないでしょうか?

PS.
この目的のために dbx の call が使用できそうな気はしますが
この命令をまともに使えたことがありません.