[ruby-dev:28202] Re: File#read にゴミがつく

唐突に 64bit Solaris を自分で試せることに気がついた
-- gcc を自分で build すれば済む話だった -- ので __fpending
を試してみました。

結論としてはうまくいきませんでした。

In article <[e-mail]>,
  Tanaka Akira <[e-mail]> writes:

> Solaris のマニュアルによれば、__fpending は出力バッファに入っているデー
> タの量を返すもので、入力バッファに入っているデータの量を得るのに使うの
> はマニュアルに無い使いかたです。
>
> 32bit Solaris で動かないのはそこが関係しているという見方もあります。
> [ruby-core:3793] 
>
> というわけで、動作が確認できた環境以外で使うのはあんまりよくないと思う
> んです。

以下のサンプルプログラムを考えます。

| % cat z.c 
| #include <stdio.h>
| #include <stdio_ext.h>
| #include <ctype.h>
| 
| int main(int argc, char **argv)
| {
|   size_t pending;
|   int c;
|   while (1) {
|     pending = __fpending(stdin);
|     printf("pending:%lu\n", pending);
|     c = getchar();
|     if (c == EOF)
|       return 0;
|     if (isprint(c))
|       printf("'%c'\n", c);
|     else
|       printf("'\\x%02x'\n", c);
|   }
| }

コンパイルすると 64bit なバイナリができます。

| % gcc -O2 -g -Wall -m64 z.c
| % file a.out 
| a.out:          ELF 64-bit MSB executable SPARCV9 Version 1,
| dynamically linked, not stripped

実行します。

| % ./a.out 
| pending:0

最初の状態では __fpending(stdin) は 0 です。これはバッファに
データが入っていないので READ_DATA_PENDING としても
READ_DATA_PENDING_COUNT としても望ましい結果です。

| abc

"abc\n" という入力を与えます。

| 'a'

getchar() が 'a' を返します。

| pending:1

この時点で、バッファには "bc\n" というデータが入っているはず
なので、READ_DATA_PENDING は真にならなくてはいけません。
__fpending(stdin) は 1 という真なので、READ_DATA_PENDING と
して使うには問題ありません。

しかし、READ_DATA_PENDING_COUNT として望ましい値はバッファに
残っている長さの 3 なので、READ_DATA_PENDING_COUNT として
__fpending を使うのは不適切です。

| 'b'
| pending:2
| 'c'
| pending:3
| '\x0a'

getchar() が '\n' を返し、バッファが空になります。

| pending:4

空になった後には、__fpending(stdin) が 4 を返します。
しかし、READ_DATA_PENDING として望ましい値はバッファが空であ
ることを意味する偽です。したがって、__fpending は
READ_DATA_PENDING として使うことも不適切です。

| ^C

バッファにデータがないので getchar は標準入力に読みにいって
ブロックし、^C で中断しています。

| % uname -srm
| SunOS 5.8 sun4u

というわけで、少なくとも SunOS 5.8 では __fpending で
READ_DATA_PENDING を定義するのは不適切なようです。
-- 
[田中 哲][たなか あきら][Tanaka Akira]