TSfree 発言

Bruce.です。
davi writes:


> > 呼び出した後は通常の fopen と変わらないはずなので、切り替えたことによって
> > 改行がそのようになってしまったというのは考えづらいのですが。
> > そもそも、オープンモードで 'b' (binary) 指定しているんだし。
> 
> ん〜…。すると、読み込みがbだからそれはチャンと効いていて、
> 出力の改行デフォがWindowsだとcrのみになるのかなぁ…。
> 
> VBAとかでも、単に改行出力させるとcrのみになるみたいだし。

CR (Carrigde Return 0x0d)ではなく、LF (Line Feed 0x0a)ではないですか?
CRが行の末尾になるのはClassic Mac 食くらいなものだと記憶しています。

 
> なお、その部分、昨日メールをpostしたあと、"rt" にしました。
> "t"だと文脈に従ったテキストモードになるんじゃないかなぁ、
> と期待してのことです。
> 
> > それ文字コード関係ありません＞＜
> 
> そっかなぁ？　crのみ、lfのみ、cr+lfとかって結構扱いが面倒ですよね。
> UTF-16のエンディアンとか、BOMの有無とかの扱いなんかと同列にイヤな
> 感じがするんですが。
> 日々コードに接していて、「そこはもう、そんなもん。」と割り切って
> 処理できるかどうか、反射能力の差なんでしょうか。

文字コード(エンコーディング)になにを使っているかということと、
改行がどのようなシーケンスなのか(CR, LF, CR+LF)は独立した別の問題です。
このエンコーディングだからLFが改行でなければならない。という縛りは
ありません。その意味で、「文字コードと関係ない」と書いています。

> でも0xffと決め打ちしているのは、どーして？
> 標準関数にそういう文字クラスなり定数なりが存在しないんでしょうか。
> ライブラリに依存する可能性があるから、それを配慮して決め打ち？
> 
> それとも、どうせ直接指定してもたいした記述量じゃないので…、
> という好みの問題？

int 抜きで int の変数を宣言してたりするところから見て、古くから
使っている人なのでしょう。1989年のANSI規格からは

/* Minimum and maximum values a `signed char' can hold.  */
#undef SCHAR_MIN
#define SCHAR_MIN (-128)
#undef SCHAR_MAX
#define SCHAR_MAX 127

/* Maximum value an `unsigned char' can hold.  (Minimum is 0).  */
#undef UCHAR_MAX
#define UCHAR_MAX 255

/* Minimum and maximum values a `char' can hold.  */
#ifdef __CHAR_UNSIGNED__
#undef CHAR_MIN
#define CHAR_MIN 0
#undef CHAR_MAX
#define CHAR_MAX 255
#else
#undef CHAR_MIN
#define CHAR_MIN (-128)
#undef CHAR_MAX
#define CHAR_MAX 127
#endif

のような定義がされていることが求められています。

ついでに書いておくと、signed も unsigned もついていない char は
"plain char"と呼ばれるもので、これはsigned でも unsigned でもありません。
コンパイラーごとにsigned であるか unsigned であるかが決まります。
小うるさいコンパイラーだと、たとえ plain char が signed char であっても
signed char と char (plain char)をキャストなしで比較したりすると警告の対象になります。

> と宣言していて、このBufに読み込んだ文字（列）を詰め込んで、常に
> 
> |	op = old_s;
> |	while ((op_remain_eval = old_e - op) > keep_len) {
> |		if ((Buf[op] & 0x8000) != 0) {
> |			op++;
> |			continue;
> |		}
> 
> みたいに比較しています。
> 
> え〜と、素人の考えかもしれませんが、これってひょっとして、せっかく
> 32ビットのアドレス空間を使えるのに、昔のコンパイラの制限であった
> 16ビット分の範囲内に制限して計算しているよ、ってことになりませんか？
> 
> もし、この理解で良いのならば、「0x8000」を「0x80000000」に
> 置換しちゃうのがホントの32ビット化だろ、ヲイ。
> ということになるんじゃないかと思うんですが、その理解でおけ？

ここだけ見ただけじゃわかりません。

いじょ。