マイクロソフトに疑問

[DDK]

こんにちは

最近MS-VC2005を本格的に導入しようとしたが、やっぱり旧来のfwrite()関数をはじめ幾つかの関数を
xxx_s(...)へ変更せよとコンパイラーに要求されました。
要は xxx_s(...)のほうは安全だと。

不思議に思うのは、
１．関数の安全性を図ろうとしたら、その中身を書き換えれば、いい話で、interface(関数名や引数の順番)を換える必要はないでしょう。

２．しっぽ(_s)の付いている関数はC++言語の国際的な標準になっているのでしょうか。


マイクロソフトより、やはりここの皆さんのご見解をお伺いするほうがいいと思いまして、、、

宜しくお願い致します。

[バグ]

Windows上でより安全に動かす為の変更であって、強要ではなかったと思いますが…

[tk-xleader]

>しっぽ(_s)の付いている関数はC++言語の国際的な標準になっているのでしょうか

それは全く違います。それを使うとMS以外のコンパイラでは全く通用しないコードになる恐れがあります。

>関数の安全性を図ろうとしたら、その中身を書き換えれば、いい話で、interface(関数名や引数の順番)を換える必要はないでしょう。

C/C++では、関数にバッファを渡すとそのバッファのサイズが引渡し先ではそのサイズを知る事ができないのです。
そこで、バッファをのサイズを関数に引き渡す事で、それを解決しようというわけです。

結論として、他環境でもコンパイルしたい場合は使わない、MS-VC2005のみでのコンパイル、そして安全性を高めるという場合は使うほうがいい。ということになるのではないでしょうか。

[DDK]

> Windows上でより安全に動かす為の変更であって、強要ではなかったと思いますが…

コンパイルする時に以下のようなメッセージが出されたので、全部"_s"の付いた関数に換えたのです。

***********************************************************************************************
セキュリティが強化されたバージョンが使用可能になったので、これらの関数は使用されなくなりました。
***********************************************************************************************

「これらの関数は使用されなくなりました」ということは"強要"に近いですね。

[a]

> やっぱり旧来のfwrite()関数をはじめ幾つかの関数を
> xxx_s(...)へ変更せよとコンパイラーに要求されました。

fwrite も警告出すの？

[tk-xleader]

>***********************************************************************************************
>セキュリティが強化されたバージョンが使用可能になったので、これらの関数は使用されなくなりました。
>***********************************************************************************************
>
>「これらの関数は使用されなくなりました」ということは"強要"に近いですね。

｢これらの関数は使用されなくなりました｣というのははっきり言って、MSの誇張です。正確に言うならば、
｢これらの標準関数は危険が伴う恐れがあります。なので、安全性の高い非標準関数を使用することを推奨します。」
がまだ正しい表現ではないでしょうか。この警告は無視してもかまいません。

ある意味でMSの体質かもしれませんね(笑)

[Justy]

　その手の関数はＣ言語の次の改訂で追加されるよう検討されているんじゃなかったでしたっけ？
　MSも標準化委員会と連絡を取り合っていたという話も昔聞いたことがあります。


http://www.open-std.org/JTC1/SC22/WG14/ ... /n1199.pdf
http://www.open-std.org/JTC1/SC22/WG14/ ... /n1193.pdf

　細かいところで MSVC版とは違ったりしますが・・・。


　セキュア関数を使わない選択をするなら

VisualC++2005 の警告メッセージについて
http://www.geocities.jp/ky_webid/common ... rning.html

　で警告を抑制するのがいいかと。

[DDK]

Justy様
>VisualC++2005 の警告メッセージについて
>http://www.geocities.jp/ky_webid/common ... rning.html

情報有難うございます。
本当に安全性に問題あれば、当然安全なものを使いたいですね。
ただ、あれは関数名のせいではなくて関数の実装の問題です。
その関数の実装を改善すればいいのにわざわざ"_s"付けて別の関数にする必要はないでしょう。

MSのC(C++)関係のソースコードにいつもごみごみに見受けます。

____...._...____
__ABCD_____.___

アンダーバーだらけで、時にはそのアンダーバーの数を数えるにも苦労。
乱暴な言語＋乱暴な命名法＝MS-VC ?

[バグ]

ぶっちゃけ、MS社の世界征服への布石ではないでしょうか？（笑）

[たかぎ]

「安全」と一口に言っても、それは何に重きを置くかによって全く変わってきます。

個人的には、移植性が保たれることの方が、つまらないミスを犯す下手糞プログラマのための対策を施している独自仕様のライブラリを使うよりずっと安全だと思います。
特定の処理系でしか使えないコードを書いてしまうのは、いわゆるセキュリティホールとは別の意味で、非常に大きな危険を伴いますから。

ところで、Linux上でGCCを使っていても、getsやtmpnamに対して、同様の露骨な警告が出ます。getsはともかく、tmpnamは代替手段が（ほぼ）ないので、そんなことを言われても、なかなかつらいところです。

[tk-xleader]

>アンダーバーだらけで、時にはそのアンダーバーの数を数えるにも苦労。
>乱暴な言語＋乱暴な命名法＝MS-VC ?

C++なので何故オーバーロードで対応しないのでしょうか。Cとの互換性？
乱暴な命名法といえば、確かWinAPIの変数命名規則はシステムハンガリアンではなかったでしょうか。MSもそれを今は廃止してますけど。

>ぶっちゃけ、MS社の世界征服への布石ではないでしょうか？（笑）

僕もそう思います。もしやMSが｢俺らのいうこと聞け!!｣という意味でこの警告出すのでは。

この関数はバッファオーバーラン対策には有効かもしれませんが。そもそもMSはコンパイラを作っているので、バッファ情報を自動的にメモリに保存する、といった実行はいるを作成することも不可能ではないはずです。それそのものは規格をは無関係のはずです

#define疑似命令によってそうするかしないか切り替えるスイッチを作ったほうがいいかもしれませんね。さっきのような実行コードは遅くなるのが必至です。

[YuO]

> ただ、あれは関数名のせいではなくて関数の実装の問題です。
> その関数の実装を改善すればいいのにわざわざ"_s"付けて別の関数にする必要はないでしょう。

関数のインターフェースが変わるのですから，別の関数にするのは自然だと思いますが。

>アンダーバーだらけで、時にはそのアンダーバーの数を数えるにも苦労。

連続するunderscoreを含むから始まる識別子は実装が使うために予約されていますから (in C++)，それでunderscoreを使っているのでしょう。

> C++なので何故オーバーロードで対応しないのでしょうか。Cとの互換性？

strcpyなどは元々Cのライブラリであることをお忘れ無く。
# 確かに<cstdio>はC++のライブラリでもありますが。

それに，

template <size_t size> errno_t std::strcpy (char (&)[size], const char *);

なんかが導入されると，配列相手の場合に

char * std::strcpy (char *, const char *);

とどちらが使われるか，直感で答えられますか？
# 基本的に非template関数は関数templateよりも強い。ただ，規格書のoverload resolutionは理解ができないのですけど……。

>> ぶっちゃけ、MS社の世界征服への布石ではないでしょうか？（笑）
> 僕もそう思います。もしやMSが｢俺らのいうこと聞け!!｣という意味でこの警告出すのでは。

なぜにこういう陰謀論が出てくるのだか……。
陰謀論に流れる前に，ちゃんと技術的な視点から警告を出している理由を考えた方がよいかと。
# 結局は，それだけバッファオーバーランによる問題が起きやすい，ということかと。

> この関数はバッファオーバーラン対策には有効かもしれませんが。そもそもMSはコンパイラを作っているので、バッファ情報を自動的にメモリに保存する、といった実行はいるを作成することも不可能ではないはずです。それそのものは規格をは無関係のはずです
> #define疑似命令によってそうするかしないか切り替えるスイッチを作ったほうがいいかもしれませんね。さっきのような実行コードは遅くなるのが必至です。

#defineどころかコンパイラスイッチやリンカスイッチでも，既に存在する関数の動作を変更することはできません。
そのことは理解していますか？
# つまりは，呼び出し側でいくら頑張ったところで既存のライブラリ(CRT含む，templateやinline系を除く)の動作を変更するのは無理だということ。

[たかぎ]

> なぜにこういう陰謀論が出てくるのだか……。
> 陰謀論に流れる前に，ちゃんと技術的な視点から警告を出している理由を考えた方がよいかと。
> # 結局は，それだけバッファオーバーランによる問題が起きやすい，ということかと。

陰謀論というのはいいすぎですね。
ただ、MSの方針に一貫性がないのは確かです。たとえば、_strdup などの非標準関数は、非標準ゆえにアンダスコアから始めています。それなら、strcpy_s も当然 _strcpy_s とすべきですよね。
私としては、<string.h> で宣言されるのも不満で、できれば <string_s.h> のようなヘッダを別に作ってほしかったところです。そうでなければ、せっかくよいライブラリが提供されていても、移植性に難があるので、結局は使えなくなります。

もうひとつ、既存のコードでこれだけ大量の警告が出て、その警告を回避する方法が詳細な説明抜きで出回ると、盲目的に警告を回避してしまうケースが続出することは必至です。

> そもそもMSはコンパイラを作っているので、

「コンパイラを作っている」ので、プロジェクトを静的解析して、問題がない strcpy 等の使用個所では警告を出さないといったことは可能なはずですね。
# コンパイル時間はかかるかもしれませんが...

[tk-xleader]

># 結局は，それだけバッファオーバーランによる問題が起きやすい，ということかと。

バッファオーバーランの問題が一番の理由だと思います。しかし｢使用されなくなった｣というのは言い過ぎではないでしょうか。

>#defineどころかコンパイラスイッチやリンカスイッチでも，既に存在する関数の動作を変更することはできません。
>そのことは理解していますか？

僕の考え方は、すでに存在する関数の表向きなど動作は変更せずに、配列の構造で対応しようというものです。
配列の一個前のアドレスに、サイズ情報を含ませておく事は、そんなに無理な話ではないと思います。
そして、バッファオーバーランが起こる前に、abort()などでプログラムを強制終了でいいのではないかと思います。
そうすれば、バッファオーバーランという最悪の事態だけは免れるのではないでしょうか。

>「コンパイラを作っている」ので、プロジェクトを静的解析して、問題がない strcpy 等の使用個所では警告を出さないといったことは可能なはずですね。

ただ、入力系統に、scanfやgetsを使うのはちょっと問題があるかなと思います。使うことに問題がある関数に対しては警告を出してもいいとは思いますが、使い方に問題がある関数は、解析してからでも問題はないと思います。

[たかぎ]

> 配列の一個前のアドレスに、サイズ情報を含ませておく事は、そんなに無理な話ではないと思います。

無理な話だと思います。
strcpy などは、必ずしも割付けられた配列の先頭を渡されるとは限りません。
例えば、

char str[16] = "0:";
strcpy(str + 2, "何か文字列");
str[0] = '1';

のようなケースは普通にあり得ますから。

> 入力系統に、scanfやgetsを使うのはちょっと問題があるかなと思います。

gets はともかく、scanf にどんな問題があるというのでしょうか？
一応、下記も参照してみてください。
http://www.kijineko.co.jp/tech/supersti ... scanf.html

[tk-xleader]

>gets はともかく、scanf にどんな問題があるというのでしょうか

これは迷信なんですね。これは勘違いしてました。

[たかぎ]

scanf 系の関数は、バッファサイズのことより、可変個引数を使っていることが一番危険です。
scanf_s 関数は、配列のサイズを size_t 型ではなく unsigned 型で指定しなければなりません。
しかし、

char str[10];
scanf_s("%9s", str, sizeof(str));

のように書いてしまうことは少なくないはずです。しかも、VC++ではたまたまこれでも動くんですね。
ところが、別の環境に移植したとたん、上のコードは突如として牙を剥きます。

また、算術型を読み込む際のオーバーフロー・アンダーフローの問題も解消されていません。
さらに、わざわざ新しく関数を実装するのに、なぜC99の書式が使えないのかもまったくの謎です。

[Justy]

> 配列のサイズを size_t 型ではなく unsigned 型で指定しなければなりません
　あ、ほんとですね。

http://msdn2.microsoft.com/ja-jp/library/w40768et(VS.80).aspx

　TRの方はちゃんと rsize_t型なのに・・・。

[Hermit]

>scanf 系の関数は、バッファサイズのことより、可変個引数を使っていることが一番危険です。
そのあたりは、プログラマが気をつけるべきことでしょう。
C,C++の精神によれば(^^;、プログラマが配慮してバグが出ない様にすればいいだけです。
いやだったら、他の言語やコンパイラで作りましょう。
（または他の言語自体を作るか、他の安全な関数を作るか）

>さらに、わざわざ新しく関数を実装するのに、なぜC99の書式が使えないのかもまったくの謎です。
ライブラリと、コンパイラ自体は、また別物だと思いますが。
バグが発生するかもしれないコンパイラの仕様変更は・・・あまりしたくは無いとは思います。
(VisualC++2005 の警告メッセージも仕様変更ではあるけど）

[たかぎ]

> >scanf 系の関数は、バッファサイズのことより、可変個引数を使っていることが一番危険です。
> そのあたりは、プログラマが気をつけるべきことでしょう。

プログラマが気をつけるべきだという意見には賛成のなのですが...
その方針であれば、

char str[10];
scanf("%9s", str);

で済むところを、わざわざミスを犯しやすい引数をもう一つ追加しないといけないのは不思議なのです。

> >さらに、わざわざ新しく関数を実装するのに、なぜC99の書式が使えないのかもまったくの謎です。
> ライブラリと、コンパイラ自体は、また別物だと思いますが。

コンパイラの話はしていません。
なぜ、scanf 系関数で、"%zu" や "%hhd", "%td" などの書式が使えないのかが謎なのです。

[Hermit]

>なぜ、scanf 系関数で、"%zu" や "%hhd", "%td" などの書式が使えないのかが謎なのです。
そんなのがあるんですか。知らなかった。
C99 に対応する気が無いんじゃなかろうかと・・・(^^;

>で済むところを、わざわざミスを犯しやすい引数をもう一つ追加しないといけないのは不思議なのです。
確かにミスしやすくなっている仕様ですね。
単純に、仕様をきちんと把握できないプログラマを排除して、
安全なプログラムを書けるプログラマだけを残すための布石ではないでしょうか (^^;

[たかぎ]

> C99 に対応する気が無いんじゃなかろうかと・・・(^^;

TR に出すのであれば、当然 C99 の書式は全サポートして然るべきですよね。

それに、いくら TR を出して、次期規格にこのライブラリを盛り込んでみても、コンパイラが最新規格に準拠していなければ、いつまでたっても独自拡張の域を出ることはできませんね。

[Hermit]

>TR に出すのであれば、当然 C99 の書式は全サポートして然るべきですよね。
ごめんなさい、TR が何か知らないので（最近プログラムの仕事にはタッチしてないので）

[たかぎ]

> ごめんなさい、TR が何か知らないので（最近プログラムの仕事にはタッチしてないので）

↓これのこと
http://www.open-std.org/JTC1/SC22/WG14/ ... /n1199.pdf