構造体のポインタ演算子のエラー

[BESSHO Tomohiro]

別所と申します
最近、家のパソコンにいれたKondara MNU/Linux-2.0 上でC言語の勉強をしていまして
その中で構造体のサンプルプログラムで以下のようなプログラムを組んだ所、
コアを吐いて終了してしまいました。

---------ここから-------------
#include <stdio.h>
#include <string.h>

struct bin{
char name[30];
int quantity;
int cost;
};

int main()
{
struct bin *cola;

(void) strcpy( cola->name, "No.1 juice");
(void) printf("property :%s \n", cola->name);

return 0;
}
---------ここまで-------------

これが
struct bin *cola;
の前の行に
int a;
といれると問題なく終了します。
どういうことになっているのか全く分かりません。
どなたかこの原因と訂正方法を教えていただけないでしょうか

----------------------------------------------
別所 智宏
三菱電機京都製作所
プロジェクション製造部LCD技術G
TEL : 090(8210)8660
E-mail : t_be...@george24.com
----------------------------------------------

[Junn Ohta]

fj.comp.lang.cの記事<20010924223920.5...@a2.sci.ne.jp>で
t_be...@a2.sci.ne.jpさんは書きました。
> その中で構造体のサンプルプログラムで以下のようなプログラムを組んだ所、
> コアを吐いて終了してしまいました。
> ...

> struct bin *cola;
>
> (void) strcpy( cola->name, "No.1 juice");

ポインターを勉強中の初心者がたいていやる間違い、い
わばFAQ中のFAQです。

「struct bin *cola;」によって宣言されるcolaは何か、
上の状況で「cola->name」はなに(どこ)を指しているか
を考えてみてください。
--
太田純(Junn Ohta) (株)リコー/新横浜事業所
oh...@sdg.mdd.ricoh.co.jp

[Kimio KASHIWAZAKI]

> struct bin{
> char name[30];
> int quantity;
> int cost;
> };

は何バイトを必要とするデータか？

> struct bin *cola;

は何バイトの領域を確保したことになるのか？
（そしてそれが何か、struct bin colaと何が違うか）

あたりから考え初めてみては如何でしょうか？

sizeof(struct bin)とsizeof(struct bin*)とを比較してみるとか
頭のなかで色々と想像力を膨らませてみて、それと何か良書の
説明とを照らしてみて。一度イメージが出来上がればそう難しい
話ではないと思います。

# ちなみにsizeof(struct bin)の結果は更に別の面白い疑問を
# 呼び起こすかも知れません。

[MIYASAKA Masaru]

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> wrote in message
news:20010924223920.5...@a2.sci.ne.jp...

> int main()
> {
> struct bin *cola;

例えばここ↑を、

| int main()
| {
| struct bin instance;
| struct bin *cola = &instance;

とか、

| #include <stdlib.h>
|
| int main()
| {
| struct bin *cola = malloc(sizeof(struct bin));

というように修正すると正常に動きます。

ポインタを使うときは、そのポインタが指している先のメモリ領域のことを
*常に* 考慮する必要があります。

> これが
> struct bin *cola;
> の前の行に
> int a;
> といれると問題なく終了します。
> どういうことになっているのか全く分かりません。

これは、この問題の本質とは関係ありません。*あなたの環境では*、
そういうふうに修正したら、偶然動いただけ、と考えるべきです。

---------------------------------
宮坂 賢 (Miyasaka, Masaru)
Asahikawa-City, Hokkaido, Japan
e-mail : alk...@coral.ocn.ne.jp

[MIYASAKA Masaru]

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> wrote in message
news:20010924223920.5...@a2.sci.ne.jp...
BESSHO Tomohiro <t_be...@a2.sci.ne.jp> wrote in message
news:20010924223920.5...@a2.sci.ne.jp...

> int main()
> {
> struct bin *cola;

例えばここ↑を、

| int main()
| {
| struct bin instance;
| struct bin *cola = &instance;

とか、

| #include <stdlib.h>
|
| int main()
| {

| struct bin *cola = malloc(sizeof(struct bin));

というように修正すると正常に動きます。

ポインタを使うときは、そのポインタが指している先のメモリ領域のことを
*常に* 考慮する必要があります。

> これが
> struct bin *cola;
> の前の行に
> int a;
> といれると問題なく終了します。
> どういうことになっているのか全く分かりません。

これは、この問題の本質とは関係ありません。*あなたの環境では*、
そういうふうに修正したら、偶然動いただけ、と考えるべきです。

> どなたかこの原因と訂正方法を教えていただけないでしょうか

他人から教えてもらった訂正方法を何も考えずにそのまま鵜呑みに
していては上達しません。「なぜそうしなければならないのか」を
考えてください。他の方もヒントを出してくれていますし。

[電子のお針箱]

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> wrote in message
news:20010924223920.5...@a2.sci.ne.jp...

> 別所と申します

> 最近、家のパソコンにいれたKondara MNU/Linux-2.0 上でC言語の勉強をしていま
> してその中で構造体のサンプルプログラムで以下のようなプログラムを組んだ所、
> コアを吐いて終了してしまいました。

(... 中略 ...)

> これが
> struct bin *cola;
> の前の行に
> int a;
> といれると問題なく終了します。

これは、たまたまご利用になっているシステムで問題ない (ように見える ?) だけ
です。

> どういうことになっているのか全く分かりません。
> どなたかこの原因と訂正方法を教えていただけないでしょうか

原因: cola の値が不定のため。
訂正方法:
どのようなことをやりたいのか良くわからないのですが、とりあえずコアを吐くの
を止めさせるだけなら...

int main()
{
struct bin x;
struct bin *cola = &x;

(void) strcpy( cola->name, "No.1 juice");
(void) printf("property :%s \n", cola->name);

return 0;
}

で良いかと思います。

# struct bin *cola = (struct bin *)malloc(sizeof struct bin); と言うものもあ
# りですけどね。

--
---------------
電子のお針箱
ue...@di.mbn.or.jp
---------------

[Inaba Hiroto]

稲葉です。

fj.comp.lang.c の <9opk9r$ga5$1...@nn-tk102.ocn.ad.jp> の
記事において 2001年09月25日(火) 18時54分26秒頃、
"MIYASAKA Masaru" <alk...@coral.ocn.ne.jp>さんは書きました。

>BESSHO Tomohiro <t_be...@a2.sci.ne.jp> wrote in message
>news:20010924223920.5...@a2.sci.ne.jp...
>> int main()
>> {
>> struct bin *cola;
>
>例えばここ↑を、
>
>| int main()
>| {
>| struct bin instance;
>| struct bin *cola = &instance;
>
>とか、
>
>| #include <stdlib.h>
>|
>| int main()
>| {
>| struct bin *cola = malloc(sizeof(struct bin));
>
>というように修正すると正常に動きます。

struct bin cola[1];

って修正は邪道ですか？
---
稲葉 浩人 in...@st.rim.or.jp

[松本 洋暁]

松本です.

"MIYASAKA Masaru" <alk...@coral.ocn.ne.jp> writes:

> > どなたかこの原因と訂正方法を教えていただけないでしょうか
>
> 他人から教えてもらった訂正方法を何も考えずにそのまま鵜呑みに
> していては上達しません。「なぜそうしなければならないのか」を
> 考えてください。他の方もヒントを出してくれていますし。

そう思ってるのなら答え教えちゃだめですよ.
ヒントが出てるのはわかっていたんでしょ?

--
======================//
Hiroaki Matsumoto // ze...@f5.dion.ne.jp
//======================

[IIJIMA Hiromitsu]

いいじまです。

> struct bin{
> char name[30];
> int quantity;
> int cost;
> };

> # ちなみにsizeof(struct bin)の結果は更に別の面白い疑問を
> # 呼び起こすかも知れません。

あのー、うちの環境では 38 になったんですけど、34 になるはずです
よね…友達は 40 になったと言っています。何がおかしいんでしょう？

＃と、答を知っていながらわざとボケをかましてみる(^^;)

========================================================================
飯嶋 浩光 / でるもんた http://www.ht.sakura.ne.jp/~delmonta/
IIJIMA Hiromitsu, aka Delmonta mailto:delm...@ht.sakura.ne.jp
mailto:delm...@pop01.odn.ne.jp

[BESSHO Tomohiro]

たくさんの方にアドバイスをいただきまして本当にありがとうございます。
ただ自分の中では理解できたのかどうか、たよりないのでもう少し。
ばかばかしいこと言っているかも知れませんがお願いします。

先のエラーの原因は、
構造体を宣言した時に
「構造体のデータ領域を示すポインタを置く領域」は確保できていても
「構造体のデータ本体を置く領域」は確保できていなかったということでしょうか？

あと、今回のエラーは、一応コンパイルを通って実行させることができるので、
「領域の確保の有無による動作の違い」が「エラーを引き起こす様」を見れないものか
と思っているのですが、その辺りを見る方法はないでしょうか？

[BESSHO Tomohiro]

別所です

> あのー、うちの環境では 38 になったんですけど、34 になるはずです
> よね…友達は 40 になったと言っています。何がおかしいんでしょう？

人によって違うんですか。中身をいろいろと変更した所、うちの環境では4バイト刻みで増減するみたいだったんで「そういうものか」と勝手に納得してましたが....

[Daisuke YAMAZAKI]

On <20010927004554.4...@a2.sci.ne.jp>

t_be...@a2.sci.ne.jp wrote:
> 別所です
>
> > あのー、うちの環境では 38 になったんですけど、34 になるはずです
> > よね…友達は 40 になったと言っています。何がおかしいんでしょう？
>
> 人によって違うんですか。中身をいろいろと変更した所、うちの環境では4バイト刻みで増減するみたいだったんで「そういうものか」と勝手に納得してましたが....

もちろんですが、人によって違うわけではないですよ:-)
環境によって違います。

やまざき(dy...@bres.tsukuba.ac.jp)

[okabe katsuyuki]

岡部です。

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:

> 先のエラーの原因は、
> 構造体を宣言した時に
> 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
> 「構造体のデータ本体を置く領域」は確保できていなかったということでしょうか？

違います。

「構造体のデータ本体を置く領域」を確保していなかった。

です。
できるできない以前に、確保するという行為自体を行っていません。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>
http://www.hinadori.dyn.to/~wills/

[okabe katsuyuki]

岡部です。

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:

> > あのー、うちの環境では 38 になったんですけど、34 になるはずです
> > よね…友達は 40 になったと言っています。何がおかしいんでしょう？
> 人によって違うんですか。中身をいろいろと変更した所、うちの環境では4バイト刻みで増減するみたいだったんで「そういうものか」と勝手に納得してましたが....

パディング(padding)とかアライメント(alignment)を調べてみましょう。

[Shigehiko SASAKI]

佐々木@でかいの です。

> あと、今回のエラーは、一応コンパイルを通って実行させることができるので、
> 「領域の確保の有無による動作の違い」が「エラーを引き起こす様」
> を見れないものかと思っているのですが、その辺りを見る方法はないでしょうか？

デバッガを使いましょう。Linuxなら gdbが利用できます。
coreファイルはエラーが生じた時のメモリ状態のスナップショットです。
デバッガを使えばcoreファイルからエラー発生時の状況を確認できます。
また最初からプログラムを実行してエラーが生じるまでの過程を観察する
こともできます。

詳しくは info gdb

coreをrmすることしか知らない人には
プロを名乗らないで欲しいと切に願う
でかいの企画 佐々木茂彦
ssa...@dekaino.net

[BESSHO Tomohiro]

> デバッガを使いましょう。Linuxなら gdbが利用できます。
> coreファイルはエラーが生じた時のメモリ状態のスナップショットです。
> デバッガを使えばcoreファイルからエラー発生時の状況を確認できます。
> また最初からプログラムを実行してエラーが生じるまでの過程を観察する
> こともできます。

一応、gdbを使ってはいます。（マニュアルめくりながらなんで、使いこなしてるとは言い難いですが）
今回の場合、全ての処理が終ってから（「return 0;」 も終ってから）
「from /lib/libc.so.6」とか書かれたエラーを出してるので
「なんじゃこりゃ」とおもったわけでして（ <- gdb が使いこなせていないから？ ）

素人考えなんでしょうが、
「最後まで処理が済んでるんだったらエラー出す必要ないやん」とか
「領域確保してないのがまずいんだったら、確保してない所に代入した時点でエラー出せんのか？」
とかかんがえてしまうわけで....

> coreをrmすることしか知らない人には
> プロを名乗らないで欲しいと切に願う

<= 名乗れるもんなんですか？ 私の中の「プロのプログラマー」のイメージが....

----------------------------------------------
別所 智宏
三菱電機京都製作所
プロジェクション製造部LCD技術G
TEL : 090(8210)8660

E-mail : t_be...@george24.co.jp
----------------------------------------------

[Junn Ohta]

fj.comp.lang.cの記事<20010927213152.6...@a2.sci.ne.jp>で
t_be...@a2.sci.ne.jpさんは書きました。
> 「領域確保してないのがまずいんだったら、確保してない所に代入した時点で
> エラー出せんのか？」

「確保してない」かどうか、というか、もっと一般的に
いえば「ポインターが正しい実体を指しているか」を調
べるには実行時にコストがかかります。C言語はそうい
うコストを省くことで効率よいプログラムを書けるよう
に設計された計算機言語なので、そういう期待をしては
いけないのです。

[Masao Seki]

半分、茶々です。
# 茶々でない半分は、ポインタの勉強途上の初心者の方へです。

okabe katsuyuki wrote:
>
> 岡部です。
>
> BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:
>
> > 先のエラーの原因は、
> > 構造体を宣言した時に
> > 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
> > 「構造体のデータ本体を置く領域」は確保できていなかったということでしょうか？
>
> 違います。
>
> 「構造体のデータ本体を置く領域」を確保していなかった。
>
> です。
> できるできない以前に、確保するという行為自体を行っていません。

それを言うなら、
ポインタ変数に、正当なアドレス（ポインタ）データが格納されないままで
ポイント先を参照したから。

と言うべきでないでしょうか。領域が確保できていても、参照できなければ
何にもなりませんよね。:-)

領域が確保できてなければ、話が始まらないと言う意味では、全く仰せの
通りなのですが・・・。

--
関＠神奈川
Masao Seki <ma-...@gb3.so-net.ne.jp>

[okabe katsuyuki]

岡部です。

Masao Seki <ma-...@gb3.so-net.ne.jp> writes:

> それを言うなら、
> ポインタ変数に、正当なアドレス（ポインタ）データが格納されないままで
> ポイント先を参照したから。
>
> と言うべきでないでしょうか。領域が確保できていても、参照できなければ
> 何にもなりませんよね。:-)

確にそうですね。

[Hiroyuki Minesita]

From article <20010927213152.6...@a2.sci.ne.jp>
by BESSHO Tomohiro <t_be...@a2.sci.ne.jp>

> 「領域確保してないのがまずいんだったら、確保してない所に代入した時点でエラー出せんのか？」
> とかかんがえてしまうわけで....

　コンパイラに未初期化のポインタを参照している旨のWarningを
出して貰うと良いのでは。
＃Cで駄目ならC++で

＃実行時に拘って全変数を0クリアしたりすると、きっと「馬鹿」
＃と言われる……

[Shinji KONO]

河野 真治@琉球大情報工学です。

In article <9ovi72$1p6$2...@ns.src.ricoh.co.jp>,
oh...@src.ricoh.co.jp (Junn Ohta) writes

>「確保してない」かどうか、というか、もっと一般的に
>いえば「ポインターが正しい実体を指しているか」を調
>べるには実行時にコストがかかります。

本当は、一度チェックすれば、あとは結構サボれるので、そんなに
大きなコストではないんですけどね。

>C言語はそうい
>うコストを省くことで効率よいプログラムを書けるよう
>に設計された計算機言語なので、そういう期待をしては
>いけないのです。

そうなんだけど、Buffer Overflow とかもそうだけど、セキュリテ
ィに関する自然なサポートが必要ですね。最近は、Safe C とかが
あるんでしたっけ。しかし使っている人はいないだろうな。

In article <9p0k17$30m8$1...@sproxy2.njk.co.jp>, Hiroyuki Minesita writes:
> 　コンパイラに未初期化のポインタを参照している旨のWarningを
> 出して貰うと良いのでは。

gcc だと -Wall で出るんでしたっけ。うちの学生に「コンパイラ
エラーは無視するな」と言っているんだけど、自分の時は、「これ
はいいの」とか言っているので、いまいち教育効果がない...

> ＃実行時に拘って全変数を0クリアしたりすると、きっと「馬鹿」
> ＃と言われる……

でも、構造体を malloc したあと zero clear するのは、もはや、
必須のようですね。へたに正しいポインタが残っていたりしますから。

---
Shinji KONO @ Information Engineering, University of the Ryukyus,
PRESTO, Japan Science and Technology Corporation
河野真治 @ 琉球大学工学部情報工学科,
科学技術振興事業団さきがけ研究21(機能と構成)

[Hisao Aoyama]

oh...@src.ricoh.co.jp (Junn Ohta) writes:

> fj.comp.lang.cの記事<20010927213152.6...@a2.sci.ne.jp>で
> t_be...@a2.sci.ne.jpさんは書きました。
> > 「領域確保してないのがまずいんだったら、確保してない所に代入した時点で
> > エラー出せんのか？」
>
> 「確保してない」かどうか、というか、もっと一般的に
> いえば「ポインターが正しい実体を指しているか」を調
> べるには実行時にコストがかかります。C言語はそうい
> うコストを省くことで効率よいプログラムを書けるよう
> に設計された計算機言語なので、そういう期待をしては
> いけないのです。

gdb を使っての話なので，言語のことではなくデバッガー
の仕様の話としてとらえるべきではないでしょうか?

1. gdb はそういう仕様のデバッガーである．

2. C 用のデバッガーでも上記問題を検出できるものもある
(インタープリターを用いたものなど)．

3. (デバッガーではないかもしれないけれど) 実行時エラー
を検出するツールでも上記問題を検出できる (こともある?)

もちろん，2 と 3 はポインターが偶然正しそうなところを
指していた場合は，実際は誤りでも検出できません．

----
Hisao Aoyama 青山 尚夫
ASTEC Products, Inc. （株）アステック・プロダクツ
aoy...@astec.co.jp

[YOSHIMOTO Hideyuki]

吉本です。

mine...@rd.njk.co.jp (Hiroyuki Minesita) writes:
> 　コンパイラに未初期化のポインタを参照している旨のWarningを
> 出して貰うと良いのでは。
> ＃Cで駄目ならC++で

お金持ちなら、purifyとかのメモリチェックツールを使うのも
良いですね。

> ＃実行時に拘って全変数を0クリアしたりすると、きっと「馬鹿」
> ＃と言われる……

たまに、
----
char szTemp[512];
memset(szTemp, NULL, sizeof(szTemp));
----
なんて書く人を見かけますが、百害あって一利なしだと思う。
（百個害を言え！といわれても困りますが）

# しかもNULLって書いちゃってるし…。

# 個人的には、szとかつける版画離暗記法
# …じゃなかったハンガリアン記法も嫌い

[Junn Ohta]

fj.comp.lang.cの記事<v41yksk...@astec.co.jp>で
aoy...@astec.co.jpさんは書きました。
> gdb を使っての話なので，言語のことではなくデバッガー
> の仕様の話としてとらえるべきではないでしょうか?

デバッガー使っても無理なものは無理よん、という話だ
ったのですが...。

> もちろん，2 と 3 はポインターが偶然正しそうなところを
> 指していた場合は，実際は誤りでも検出できません．

というか、検出できる場面のほうが圧倒的に少ないので
はないですか?

[Kazuo Fox Dohzono]

In article <15215.10...@insigna.ie.u-ryukyu.ac.jp>
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

> でも、構造体を malloc したあと zero clear するのは、もはや、
> 必須のようですね。へたに正しいポインタが残っていたりしますから。

malloc ではなくても, struct sockaddr_in なんかを自動変数で確保するとこ
ちらが必須だと思った項目を設定しただけではうまく動作してくれなかったこ
とがあります.

# 確か Stevens 本では一々クリアするコードが入っていた気がしますが, そ
# のことに関する説明は見た記憶がありません. 対応するソース読めってこと?

--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp

[12],(6,9),0,0,2
(2/2412/5263)

[KATAYAMA Yoshio]

In article <15215.10...@insigna.ie.u-ryukyu.ac.jp>,
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:

>でも、構造体を malloc したあと zero clear するのは、もはや、
>必須のようですね。へたに正しいポインタが残っていたりしますから。

そういうあなたに calloc()。
--
片山＠ＰＦＵ

[Kazuo Fox Dohzono]

In article <KATE.01Se...@flash.tokyo.pfu.co.jp>
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:

> >でも、構造体を malloc したあと zero clear するのは、もはや、
> >必須のようですね。へたに正しいポインタが残っていたりしますから。
>
> そういうあなたに calloc()。

7.20.3.1 The calloc function

の注釈に

Note that this need not be the same as the representation
of floating-point zero or a null pointer constant.

とありますけど, 問題ないんでしょうか.

[電子のお針箱]

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message
news:86elotss...@hgc02147.nifty.ne.jp...

> > 先のエラーの原因は、
> > 構造体を宣言した時に
> > 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
> > 「構造体のデータ本体を置く領域」は確保できていなかったということでしょう
> > か？
>
> 違います。
>
> 「構造体のデータ本体を置く領域」を確保していなかった。

「確保していなかった」から「確保できていなかった」だけでしょ ?

# 間違ったことは言ってないと思いますけど...。

Shigehiko SASAKI <ssa...@dekaino.net> wrote in message
news:rm8zf13...@emma.dekaino.net...

> > あと、今回のエラーは、一応コンパイルを通って実行させることができるので、
> > 「領域の確保の有無による動作の違い」が「エラーを引き起こす様」
> > を見れないものかと思っているのですが、その辺りを見る方法はないでしょう
> > か ？

> デバッガを使いましょう。

という意見はもっともですけど、アセンブラが読めないと今回の「エラーを引き起
こす様」をみるのは難しいかと思いますが...。

# もっとも、難しいから止めとくと言うような人は C 言語なんか使わない方が良い
# とも思います。

> Linuxなら gdbが利用できます。

cc の -g オプションを調べておくとより幸せかもしれません。> 別所さん

[Junn Ohta]

fj.comp.lang.cの記事<9p1uct$oce$2...@newsjp.mbn.or.jp>で
ueno-...@di.mbn.or.jpさんは書きました。

> 「確保していなかった」から「確保できていなかった」だけでしょ ?

違うんじゃないかなあ。

元の文は「構造体を宣言した時に……確保できていなか
った」なんですから、「その宣言によって確保したつも
りだった(のだがそうではなかった)」ということだと思
いますよ。

[IIJIMA Hiromitsu]

いいじまです。

> > > 「領域確保してないのがまずいんだったら、確保してない所に代入した時点で
> > > エラー出せんのか？」
> >
> > 「確保してない」かどうか、というか、もっと一般的に
> > いえば「ポインターが正しい実体を指しているか」を調
> > べるには実行時にコストがかかります。C言語はそうい
> > うコストを省くことで効率よいプログラムを書けるよう
> > に設計された計算機言語なので、そういう期待をしては
> > いけないのです。
>
> gdb を使っての話なので，言語のことではなくデバッガー
> の仕様の話としてとらえるべきではないでしょうか?
>
> 1. gdb はそういう仕様のデバッガーである．
>
> 2. C 用のデバッガーでも上記問題を検出できるものもある
> (インタープリターを用いたものなど)．

そういうデバッガもあるみたいですよ。
http://www.pro.or.jp/~fuji/mybooks/cdiag/index.html
の第 10 章にこれに関する記述があります。
…そこで紹介されているデバッガ、ものすごく高価ですけど。

[S.Masa]

S.Masa です．

"YOSHIMOTO Hideyuki" wrote
<uheto8...@siren.ocn.ne.jp>
about "Re: 構造体のポインタ演算子のエラー"
on 28 Sep 2001 12:25:16 +0900

>----
> char szTemp[512];
> memset(szTemp, NULL, sizeof(szTemp));
>----
>なんて書く人を見かけますが、百害あって一利なしだと思う。

なぜですか？
ある法則に基いて配列に値を格納していく．その結果を演算する．
格納されていないところは演算を省く．
そういった場合に，省く為のチェックにある値をはじめに一括で代入しておくっ
てのはよくやる手だと思うんですが．．．．

2001/09/29(Sat) 03:02:07
--
Word by Ｓ．Ｍａｓａ
masa.s...@nifty.ne.jp
http://homepage2.nifty.com/DSS/

[Kazuo Fox Dohzono]

In article <20010929030209.6...@nifty.ne.jp>
S.Masa <masa.s...@nifty.ne.jp> writes:

> >----
> > char szTemp[512];
> > memset(szTemp, NULL, sizeof(szTemp));
> >----
> >なんて書く人を見かけますが、百害あって一利なしだと思う。
>
> なぜですか？

宗教上の理由から「bzero 使え」ってことだったりして :-p

[H.Yamaguchi]

"Kazuo Fox Dohzono" <doh...@hf.rim.or.jp> wrote in message
news:9p3f0b$h8g$1...@news2.rim.or.jp

>
>> >----
>> > char szTemp[512];
>> > memset(szTemp, NULL, sizeof(szTemp));
>> >----
>> >なんて書く人を見かけますが、百害あって一利なしだと思う。
>>
>> なぜですか？
>
> 宗教上の理由から「bzero 使え」ってことだったりして :-p

　実は広域変数だったとか？ (^^;

--
山口@福岡 <hy...@mx7.tiki.ne.jp>

[okabe katsuyuki]

岡部です。

S.Masa <masa.s...@nifty.ne.jp> writes:

> >----
> > char szTemp[512];
> > memset(szTemp, NULL, sizeof(szTemp));
> >----
> >なんて書く人を見かけますが、百害あって一利なしだと思う。
>
> なぜですか？
> ある法則に基いて配列に値を格納していく．その結果を演算する．
> 格納されていないところは演算を省く．
> そういった場合に，省く為のチェックにある値をはじめに一括で代入しておくっ
> てのはよくやる手だと思うんですが．．．．

この場合だと、memset(szTemp, NULL, sizeof(szTemp)); は

for (i = 0; i < sizeof(szTemp); i++) {
szTemp[i] = NULL;
}

と同義なんですけど、どこがおかしいのかわかりませんか？

[Junn Ohta]

fj.comp.lang.cの記事<864rpm6w...@hgc02147.nifty.ne.jp>で
hgc0...@nifty.ne.jpさんは書きました。

> この場合だと、memset(szTemp, NULL, sizeof(szTemp)); は
> for (i = 0; i < sizeof(szTemp); i++) {
> szTemp[i] = NULL;
> }
> と同義なんですけど、

元記事の吉本さんは自分で
| # しかもNULLって書いちゃってるし…。
と書いているので、NULLの部分を差し引いてもまだおか
しいといいたいのだと思いますが。

接頭辞szから、この配列にはASCIZ文字列しか格納され
ないことが明白なので、先頭から見ていって最初に'\0'
が出現する位置以降に何かを書き込むのは無意味です。
初期化したいのなら
*szTemp = '\0'
で必要十分でしょう。

[Shin-ichi TSURUTA]

Junn Ohtaさん、こんにちは、鶴田(SYN)です。

oh...@src.ricoh.co.jp (Junn Ohta) wrote:
> fj.comp.lang.cの記事<864rpm6w...@hgc02147.nifty.ne.jp>で
> hgc0...@nifty.ne.jpさんは書きました。
> > この場合だと、memset(szTemp, NULL, sizeof(szTemp)); は
> > for (i = 0; i < sizeof(szTemp); i++) {
> > szTemp[i] = NULL;
> > }
> > と同義なんですけど、
>
> 元記事の吉本さんは自分で
> | # しかもNULLって書いちゃってるし…。
> と書いているので、NULLの部分を差し引いてもまだおか
> しいといいたいのだと思いますが。

まず、これが、ある場合についてなのか、すべての場合についてな
のか明確でないのが問題だし、背景となる環境・条件・目的がわか
らないと何ともいえないと思います。

> 接頭辞szから、この配列にはASCIZ文字列しか格納され
> ないことが明白なので、先頭から見ていって最初に'\0'

まず、どのようなハンガリアン記法が使われているかは、不明です
よね。ちなみに私の場合、独自のハンガリアン記法を使っています。

> が出現する位置以降に何かを書き込むのは無意味です。
> 初期化したいのなら
> *szTemp = '\0'
> で必要十分でしょう。

多くの場合無意味でしょうが、配列自体を特殊なソーティング(ラ
ディックスソートなど)に掛ける場合のように、全初期化が必要な
例は確かにあります。
____________________________________________________________
Name : Shin-ichi TSURUTA 鶴田 真一 (as SYN)
E-mail : syn...@pop21.odn.ne.jp
URL : http://www1.odn.ne.jp/synsyr/

[電子のお針箱]

Junn Ohta <oh...@src.ricoh.co.jp> wrote in message
news:9p22cf$pua$1...@ns.src.ricoh.co.jp...

> 元の文は「構造体を宣言した時に……確保できていなか
> った」なんですから、「その宣言によって確保したつも
> りだった(のだがそうではなかった)」ということだと思
> いますよ。

この解釈については異論はありませんが、だからと言って...

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:

> 「構造体のデータ本体を置く領域」は確保できていなかった

と言う事実について、

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message
news:86elotss...@hgc02147.nifty.ne.jp...

> 違います。

とまで言えるのでしょうか ?

[okabe katsuyuki]

岡部です。

oh...@src.ricoh.co.jp (Junn Ohta) writes:

> 元記事の吉本さんは自分で
> | # しかもNULLって書いちゃってるし…。
> と書いているので、NULLの部分を差し引いてもまだおか
> しいといいたいのだと思いますが。

NULL使っている以外におかしい所だと私にはわからないなぁ。
szTempがどういう使われ方するのかわからないから、全要素の初期化が無駄か
どうかもわからないし。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[okabe katsuyuki]

岡部です。

電子のお針箱 <ueno-...@di.mbn.or.jp> writes:

> BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:
> > 「構造体のデータ本体を置く領域」は確保できていなかった
> と言う事実について、

「してない」と「できない」って同じ意味なんでしょうか？

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[Yoshiki Kataoka]

片岡＠ちゃちゃです。

> パディング(padding)とかアライメント(alignment)を調べてみましょう。

ん？

# 問題：　以下の各語をカタカナ表記せよ
# simulator
# glitch
# Bjarne
# processor
# super user

[Yoshiki Kataoka]

片岡です。

> 本当は、一度チェックすれば、あとは結構サボれるので、そんなに
> 大きなコストではないんですけどね。

そう、結構サボれますね。
一度めのチェックも同じ理由で。

○○がチェック済みだから△△をチェックする必要はない。
□□がチェック済みだから○○をチェックする必要はない。
☆☆がチェック済みだから□□をチェックする必要はない。
一度めのチェック条件はどこにあるのか．．．

# assert のコストが小さくないから NDEBUG がある

> そうなんだけど、Buffer Overflow とかもそうだけど、セキュリテ
> ィに関する自然なサポートが必要ですね。最近は、Safe C とかが
> あるんでしたっけ。しかし使っている人はいないだろうな。

みんな「Ｃを使っている」んでしょうね。

> gcc だと -Wall で出るんでしたっけ。うちの学生に「コンパイラ
> エラーは無視するな」と言っているんだけど、自分の時は、「これ
> はいいの」とか言っているので、いまいち教育効果がない...

一度めのチェック条件はどこに？
講師の資質が問われる場面ですね。

# ところで
# void *p, f(void **), g(void *);
# f(&p);
# で「これはいいの」って警告出ましたっけ？
# g(p);
# ならともかく

> でも、構造体を malloc したあと zero clear するのは、もはや、
> 必須のようですね。へたに正しいポインタが残っていたりしますから。

「必須」という部分に反対です。
不定か否かが区別できない＝ロジックが書けない

Ｃでこれをさて置いては他言語の代用に使っているに過ぎません。

[Yoshiki Kataoka]

片岡です。

> malloc ではなくても, struct sockaddr_in なんかを自動変数で確保するとこ
> ちらが必須だと思った項目を設定しただけではうまく動作してくれなかったこ
> とがあります.
>
> # 確か Stevens 本では一々クリアするコードが入っていた気がしますが, そ
> # のことに関する説明は見た記憶がありません. 対応するソース読めってこと?

残念ながら、それが現実のようですね。
ドキュメントにない「仕様」をソースから読めとか
２万５千円／時で質問権を買ってやっと聞き出せた
というのは、私が見た範囲だけでもザラです。

# 質問権を行使したら回答が「マニュアル読め」でブチ切れた元同僚もいた．．．
# 断じて「正し」くないのよね

[Takasuka Yoshihiro]

高須賀@WAKWAKです。

電子のお針箱 <ueno-...@di.mbn.or.jp> さんの<9p66b8$qst$3...@newsjp.mbn.or.jp>から

>Junn Ohta <oh...@src.ricoh.co.jp> wrote in message
>news:9p22cf$pua$1...@ns.src.ricoh.co.jp...
>
>> 元の文は「構造体を宣言した時に……確保できていなか
>> った」なんですから、「その宣言によって確保したつも
>> りだった(のだがそうではなかった)」ということだと思
>> いますよ。
>
> この解釈については異論はありませんが、だからと言って...

この解釈に異論が無いのだったら、

>BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:
>
>> 「構造体のデータ本体を置く領域」は確保できていなかった
>
>と言う事実について、
>
>okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message
>news:86elotss...@hgc02147.nifty.ne.jp...
>
>> 違います。
>
>とまで言えるのでしょうか ?

なんで言えないんでしょうか？

# どの部分の解釈がグレーになるか全くわからないんですが、、、

--
Takasuka Yoshihiro mailto:tes...@bc.wakwak.com

[電子のお針箱]

# 半分茶々です。

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message

news:86zo7d9...@hgc02147.nifty.ne.jp...

> NULL使っている以外におかしい所だと私にはわからないなぁ。
> szTempがどういう使われ方するのかわからないから、全要素の初期化が無駄か
> どうかもわからないし。

それを言うなら、NULL 使っていること自体もおかしいとは言えないですよね。

# NULL がどういう定義されているかわからないから。

# 個人的には、太田さんの 9p4l1i$l07$1...@ns.src.ricoh.co.jp ぐらいが、まと
# もな解釈と思います。

[電子のお針箱]

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message

news:86n13d9m...@hgc02147.nifty.ne.jp...

> > BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:
> > > 「構造体のデータ本体を置く領域」は確保できていなかった
> > と言う事実について、
>
> 「してない」と「できない」って同じ意味なんでしょうか？

もちろんこの二つの意味は違いますよ。でも、今回の場合は両方とも正しいんじゃ
ないですか ?

# だから、「「確保していなかった」から「確保できていなかった」だけでしょ ?」
# と書いたのですけど。

[BESSHO Tomohiro]

分かりにくい書き方をしてしまって申し訳ありません。
結局、この辺りの齟齬の大元は私の間違いからきてるので論争にされると心苦しいですが....

「したと思っていた」ら、（プログラム上では）「していなかった」 ー＞ （私が）「できていなかった」

わたしは、回答をして下さった方々のように「使いこなしている」わけではなく
学習の途上にあるので（個人の能力として「できないこと」を「できる」様にすることが目的なので）
質問の中でわたし個人の感情を込めて「確保できていなかった」と言ってしまったのです。

私の個人的背景無しにプログラムをみれば、単に「していない」ということになります
お騒がせして申し訳ないです m(_ _)m

> > > BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:
> > > > 「構造体のデータ本体を置く領域」は確保できていなかった
> > > と言う事実について、
> >
> > 「してない」と「できない」って同じ意味なんでしょうか？
>
> もちろんこの二つの意味は違いますよ。でも、今回の場合は両方とも正しいんじゃ
> ないですか ?
>
> # だから、「「確保していなかった」から「確保できていなかった」だけでしょ ?」
> # と書いたのですけど。

----------------------------------------------
別所 智宏
三菱電機京都製作所
プロジェクション製造部LCD技術G
TEL : 090(8210)8660
E-mail : t_be...@george24.com
----------------------------------------------

[Junn Ohta]

fj.comp.lang.cの記事<9p5mds$236c$1...@nwall1.odn.ne.jp>で
syn...@pop21.odn.ne.jpさんは書きました。

> まず、どのようなハンガリアン記法が使われているかは、不明です
> よね。ちなみに私の場合、独自のハンガリアン記法を使っています。

オリジナルのハンガリアン記法にあるszという接頭辞を
オリジナルと違う意味で使っているとしたら、今回の謎
掛けには正しい回答に到達する手段がないことになりま
すね。

ま、いずれにしても「あのコードを示したのはこういう
意味でした」というフォローがあれば明らかになること
なので、気楽に待ちましょう。:-)

> 多くの場合無意味でしょうが、配列自体を特殊なソーティング(ラ
> ディックスソートなど)に掛ける場合のように、

そんなデータに(オリジナルのハンガリアン記法でいう
ところの)szなどという接頭辞をつけてはイカンです。

[Junn Ohta]

fj.comp.lang.cの記事<9p66b8$qst$3...@newsjp.mbn.or.jp>で
ueno-...@di.mbn.or.jpさんは書きました。
> > 「構造体のデータ本体を置く領域」は確保できていなかった
> と言う事実について、
> ...
> > 違います。
> とまで言えるのでしょうか ?

「違います」は
> > 「構造体のデータ本体を置く領域」は確保できていなかった
「と言う事実」に対するものではなくて、文章全体に対
する答えでしょう。それは岡部さんのその後の文章から
も明らかだと思います。

[Junn Ohta]

fj.comp.lang.cの記事<20010930231843.2...@a2.sci.ne.jp>で
t_be...@a2.sci.ne.jpさんは書きました。
> 分かりにくい書き方をしてしまって申し訳ありません。
> 結局、この辺りの齟齬の大元は私の間違いからきてるので論争にされると心苦しいですが....

ネタ配給元の別所さんが恐縮される必要はないです。こ
こに出てきている人たちはみなそれなりに議論を楽しん
でいるのですから。

> 私の個人的背景無しにプログラムをみれば、単に「していない」ということになります

そのとおりなんですけど、これは初心者がとくに陥りや
すい問題なので、どうして「これで確保できたはず」と
思い込んでしまったのか、というあたりに議論に参加し
ている面々の興味が集中しているわけです。

「違います」という発言はそのあたりを見越したうえで
「確保したつもり」が間違っているのだということを指
摘しているわけですが、そういう指摘のしかたを好まな
い人もいて、別のルートをたどろうとしているのですね。

別所さんも、これらの議論を眺めて各人がどういうスタ
ンスで発言しているのかを理解すれば、今後のC言語の
習得に役立つのではないかと思います。

[Shin-ichi TSURUTA]

Junn Ohtaさん、こんにちは、鶴田(SYN)です。

oh...@src.ricoh.co.jp (Junn Ohta) wrote:
> > 多くの場合無意味でしょうが、配列自体を特殊なソーティング(ラ
> > ディックスソートなど)に掛ける場合のように、
>
> そんなデータに(オリジナルのハンガリアン記法でいう
> ところの)szなどという接頭辞をつけてはイカンです。

太田さんいう、オリジナルのハンガリアン記法だったとしても、

その場合、どういう接頭辞をつけますか？

ASCIZ文字列であり、最後尾まで0が埋める場合がある配列にはszを
つけてはいけないという理由はないと思います。

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message
> news:86zo7d9...@hgc02147.nifty.ne.jp...
>
> > NULL使っている以外におかしい所だと私にはわからないなぁ。
> > szTempがどういう使われ方するのかわからないから、全要素の初期化が無駄か
> > どうかもわからないし。
>
> それを言うなら、NULL 使っていること自体もおかしいとは言えないですよね。
>
> # NULL がどういう定義されているかわからないから。

処理系によって定義は異なりますが、例え0に定義されていても、
NULLは空ポインタ定数なので、これはどんな場合でもマズイです。
# NULLとNULは違いますし、バグらなければ良いという話でもない。

参考
「CプログラミングFAQ」(ISBN4-8101-8097-2)
の5.9より一部抜粋。

　ポインタが必要なところでのみNULLと0は同等である。NULLを、
ポインタ以外の0が必要な場面に使ってはならない。プログラム
は動くかもしれないが、コンパイラに間違ったメッセージを送っ
ていることに違いはない(ANSIはNULLの定義に(void *)0を使うこ
とを許している。この場合ポインタ以外が必要な場合は全然うま
くいかない)。とくにASCIIのヌル文字(NUL)が必要な場合は、
絶対にNULLを使ってはならない。慣例的表現の定数が必要なら自分で
▲▲▲▲▲▲▲▲▲▲▲▲▲▲

#define NUL '\0'

を用意すること。

[Takasuka Yoshihiro]

高須賀@WAKWAKです。

ハンガリアンで書かないけど、なぜかいくつか覚えてるので、、、

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> さんの<9p7kh8$2fno$1...@nwall1.odn.ne.jp>から

>Junn Ohtaさん、こんにちは、鶴田(SYN)です。
>
>oh...@src.ricoh.co.jp (Junn Ohta) wrote:
>> > 多くの場合無意味でしょうが、配列自体を特殊なソーティング(ラ
>> > ディックスソートなど)に掛ける場合のように、
>>
>> そんなデータに(オリジナルのハンガリアン記法でいう
>> ところの)szなどという接頭辞をつけてはイカンです。
>
>太田さんいう、オリジナルのハンガリアン記法だったとしても、
>
>その場合、どういう接頭辞をつけますか？

MSのプログラマーが発明したハンガリアン記法に従うなら
sz は ASCIIZ文字列の接頭辞と決まってるので、配列をバイト配列として扱う
なら、by とか b ですし、char 型の配列として扱うのなら c です。

配列として宣言する場合は lp,p などのポインタ用の接頭辞は付けてはいけま
せん。

>ASCIZ文字列であり、最後尾まで0が埋める場合がある配列にはszを
>つけてはいけないという理由はないと思います。

最後尾まで、0 で埋める必要がある物は、ASCIIZ文字列では無いような気がし
ますが、、、、
ASCIIZ文字列は終端記号によって終了する文字列なので、最後の終端記号以降
が参照される可能性はないことを前提にしてます。
終端記号以降の領域も、0 で埋めておく*必要がある*のならは、それはASCIIZ
文字列以外の文字列という事になるので接頭辞は s だったような気がします
が、さすがに記憶に無いです。

ただの揚げ足とりですが、szTemp をハンガリアン記法の ASCIIZ文字列と推論
するとしても太田さんの言うとおり、
*szTemp='\0'
だけでいいかっていうと、
UNICODE文字列とかの場合は、2byte連続の'\0'が終端記号になってたりするん
で、この例では szTempが char宣言なので
szTemp[0]=szTemp[1]='\0'
が必要になる場合も考えられるかなぁっとか。

もちろん、3byteとかそれ以外のケースも考えられますけど。
いずれにしろ先頭の終端記号の初期化以上は必要ないと思います。

[Shin-ichi TSURUTA]

Takasuka Yoshihiroさん、こんにちは、鶴田(SYN)です。

Takasuka Yoshihiro <tes...@bc.wakwak.com> wrote:
> >> > 多くの場合無意味でしょうが、配列自体を特殊なソーティング(ラ
> >> > ディックスソートなど)に掛ける場合のように、
> >> そんなデータに(オリジナルのハンガリアン記法でいう
> >> ところの)szなどという接頭辞をつけてはイカンです。
> >太田さんいう、オリジナルのハンガリアン記法だったとしても、
> >その場合、どういう接頭辞をつけますか？
>
> MSのプログラマーが発明したハンガリアン記法に従うなら
> sz は ASCIIZ文字列の接頭辞と決まってるので、配列をバイト配列として扱う
> なら、by とか b ですし、char 型の配列として扱うのなら c です。

ええ、でも先頭から普通にアクセスする場合ASCIZ文字列であるな
らば、szとつけても問題は無いと思います。

> >ASCIZ文字列であり、最後尾まで0が埋める場合がある配列にはszを
> >つけてはいけないという理由はないと思います。
>
> 最後尾まで、0 で埋める必要がある物は、ASCIIZ文字列では無いような気がし
> ますが、、、、

# ASCIIZでなく、ASCIZじゃなかったっけ？どっちでも良いかな。(^^;

必要があるかどうかではなく、文字列の最後がNULというだけで、
それ以降どのような値が入っていてもいいはずです。従って、ASCIZ
文字列だといいながら、終端以降のエリアを好きなように初期化し、
他の処理をしやすく利用しても問題はないと思うのです。

> ASCIIZ文字列は終端記号によって終了する文字列なので、最後の終端記号以降
> が参照される可能性はないことを前提にしてます。

ですが、それ以外の利用を禁止するものではないと思うのです。
というのは、

char szTemp[512];
▲▲ ▲▲▲

というように、あくまでchar型の配列なので、それを前提とした利
用をしても良いと思うのです。これがダメなんて言われたら「キャ
スト」という行為も許されないのではないでしょうか。

> 終端記号以降の領域も、0 で埋めておく*必要がある*のならは、それはASCIIZ
> 文字列以外の文字列という事になるので接頭辞は s だったような気がします
> が、さすがに記憶に無いです。

私が言っているのは、文字列として利用する時は常に、ASIZ文字列
として利用でき、特に必然ではないが、効率の良いソートのために
終端以降0で埋めるような利用をしても良いのではないかということ
です。

[Takasuka Yoshihiro]

高須賀@WAKWAKです。

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> さんの<9p7ue5$ujl$1...@nwall2.odn.ne.jp>から

>Takasuka Yoshihiroさん、こんにちは、鶴田(SYN)です。
>
>Takasuka Yoshihiro <tes...@bc.wakwak.com> wrote:
>> MSのプログラマーが発明したハンガリアン記法に従うなら
>> sz は ASCIIZ文字列の接頭辞と決まってるので、配列をバイト配列として扱う
>> なら、by とか b ですし、char 型の配列として扱うのなら c です。
>
>ええ、でも先頭から普通にアクセスする場合ASCIZ文字列であるな
>らば、szとつけても問題は無いと思います。

ASCIIZ 文字列として扱うのは sz で問題ないです。

># ASCIIZでなく、ASCIZじゃなかったっけ？どっちでも良いかな。(^^;

どっちでしたっけ、自分ではなんとなく ASCIIZ って昔から書いてたんですが、
確認した事一度も無いです。

>必要があるかどうかではなく、文字列の最後がNULというだけで、
>それ以降どのような値が入っていてもいいはずです。従って、ASCIZ
>文字列だといいながら、終端以降のエリアを好きなように初期化し、
>他の処理をしやすく利用しても問題はないと思うのです。

それは問題ないとも思うんですが、後からメンテする人に終端記号以降も こ
れこれの処理で、こういう構造にするから必ず終端記号以降も初期化してね。
っていう事を伝えないといけなくなりますよね。
コーディング中は、この事が自明のこととして、頭に入ってると思いますが、
時間が空いて全く別の人がメンテする時に、同じ接頭辞を使うのは、混乱する
原因になりませんか？
名前でデータ型を判定する事にして、若干とはいえ拡張された使い方をするの
であれば区別した方がいいように思います。

>> ASCIIZ文字列は終端記号によって終了する文字列なので、最後の終端記号以降
>> が参照される可能性はないことを前提にしてます。
>
>ですが、それ以外の利用を禁止するものではないと思うのです。
>というのは、
>
> char szTemp[512];
> ▲▲ ▲▲▲
>
>というように、あくまでchar型の配列なので、それを前提とした利
>用をしても良いと思うのです。これがダメなんて言われたら「キャ
>スト」という行為も許されないのではないでしょうか。

一応、ハンガリアン記法上はプログラム上で char 型の配列として扱うなら接
頭辞は c にすべきと言う事になってます。
char 型の配列ならただの配列ですんで、各要素をどう使おうと自由ですよね。

キャストして別の変数に代入すると、そっちの変数の接頭辞が意味を持ちます
よね。

ハンガリアン記法の主旨からいくと接頭辞でデータ構造を(ある程度)表現した
いという事だと思われるので、終端記号以降が意味の無いものと、終端記号以
降も一応、空データの並びになっているとはいえ一応、意味がある文字列とで、
同じ接頭辞を使うのでは、ハンガリアン記法を使う意味が無いように思います。

ハンガリアン記法を考えついたMSの人はデータの型と目的との区別をせずにこ
ういう規則を作ったようで、ちょっとでも(ハンガリアン記法の)基本から外れ
たデータ構造には対応しきれないのような気がします。
その度に逐一新しい接頭辞を作れと言う事なのかもしれませんが、、、

>> 終端記号以降の領域も、0 で埋めておく*必要がある*のならは、それはASCIIZ
>> 文字列以外の文字列という事になるので接頭辞は s だったような気がします
>> が、さすがに記憶に無いです。
>
>私が言っているのは、文字列として利用する時は常に、ASIZ文字列
>として利用でき、特に必然ではないが、効率の良いソートのために
>終端以降0で埋めるような利用をしても良いのではないかということ
>です。

そういう文字列を利用してはいけないという事は全然無いんですが、、、
・終端記号以降を全く気にしない
・終端記号以降を初期化しておくと効率がいい
・終端記号以降を初期化しておかなくてはいけない。
の3つ文字列は私は別のデータ構造だと考えます。
なので私の場合はハンガリアン記法を使うならば、接頭辞として別の物を用意
して区別すべきだと考えます。
sz,sza,szb みたいな感じでそれぞれを分けて sz を引数とする関数は場合は、
sza,szb も指定可、sza,szb->sz はstrcpy が可だけど、sz->szb は専用の関
数を利用って感じです。

個人的には、ハンガリアン記法は使ってないんで実際そう書いてるかって言わ
れたら書いた事ないんですが、、、

[Shin-ichi TSURUTA]

Takasuka Yoshihiroさん、こんにちは、鶴田(SYN)です。

Takasuka Yoshihiro <tes...@bc.wakwak.com> wrote:
> >必要があるかどうかではなく、文字列の最後がNULというだけで、
> >それ以降どのような値が入っていてもいいはずです。従って、ASCIZ
> >文字列だといいながら、終端以降のエリアを好きなように初期化し、
> >他の処理をしやすく利用しても問題はないと思うのです。
>
> それは問題ないとも思うんですが、後からメンテする人に終端記号以降も こ
> れこれの処理で、こういう構造にするから必ず終端記号以降も初期化してね。
> っていう事を伝えないといけなくなりますよね。
> コーディング中は、この事が自明のこととして、頭に入ってると思いますが、
> 時間が空いて全く別の人がメンテする時に、同じ接頭辞を使うのは、混乱する
> 原因になりませんか？
> 名前でデータ型を判定する事にして、若干とはいえ拡張された使い方をするの
> であれば区別した方がいいように思います。

うーん、確かにそうですね。

ただ、複数の人間で開発していて、自分以外の開発者がその構造体
にアクセスする場合は完全にASCIZ文字列であり、終端以降を気に
する必要はないのだが、自分のルーチンであとからソートする必要
が出てきたために、0を埋めて利用するというような場合、別の配列
を作ってコピーしたり、他の開発者にszからcに変更するように要求
することまでする必要があるのだろうかとか、悩んでしまいます。

> 一応、ハンガリアン記法上はプログラム上で char 型の配列として扱うなら接
> 頭辞は c にすべきと言う事になってます。
> char 型の配列ならただの配列ですんで、各要素をどう使おうと自由ですよね。

んー、なら、

union{
char szTemp[512];
char cTemp[512];
};

とかすればいいのかなぁ。

> ハンガリアン記法の主旨からいくと接頭辞でデータ構造を(ある程度)表現した
> いという事だと思われるので、終端記号以降が意味の無いものと、終端記号以
> 降も一応、空データの並びになっているとはいえ一応、意味がある文字列とで、
> 同じ接頭辞を使うのでは、ハンガリアン記法を使う意味が無いように思います。
>
> ハンガリアン記法を考えついたMSの人はデータの型と目的との区別をせずにこ
> ういう規則を作ったようで、ちょっとでも(ハンガリアン記法の)基本から外れ
> たデータ構造には対応しきれないのような気がします。

御意。

> その度に逐一新しい接頭辞を作れと言う事なのかもしれませんが、、、

最近、これで悩むことが多いんです(T_T)。

> 個人的には、ハンガリアン記法は使ってないんで実際そう書いてるかって言わ
> れたら書いた事ないんですが、、、

私もかなり使わない方で抵抗していたのですが、引数からメンバ変
数へのコピーや、関数へのポインタアクセスとその関数名のように、
同じ名前が使える誘惑に負けて、使い出しました(苦笑)。

[Junn Ohta]

fj.comp.lang.cの記事<9p7rt8$144p$1...@news1.wakwak.com>で
tes...@bc.wakwak.comさんは書きました。
> ただの揚げ足とりですが、

bootstrapというやつですね。:-)

> UNICODE文字列とかの場合は、2byte連続の'\0'が終端記号になってたりするん
> で、この例では szTempが char宣言なので
> szTemp[0]=szTemp[1]='\0'
> が必要になる場合も考えられるかなぁっとか。

型がcharですし、わざわざASCIZと書き加えたことも含
めて、複数バイトの終端が必要な場合は除外しておいた
つもりです。

それに、ハンガリアン記法の主旨から考えても、接頭辞
から操作方法が一意に決まってくれなければ困るわけで、
内容を見なければ終端の認識のしかたが確定しないとい
うのはおかしな話です。上記の場合はsz以外の接頭辞を
付けるというのがハンガリアン記法としては正しい道筋
なんでしょう。

[Junn Ohta]

fj.comp.lang.cの記事<9p86c8$1emu$1...@nwall2.odn.ne.jp>で
syn...@pop21.odn.ne.jpさんは書きました。

> ただ、複数の人間で開発していて、自分以外の開発者がその構造体
> にアクセスする場合は完全にASCIZ文字列であり、終端以降を気に
> する必要はないのだが、自分のルーチンであとからソートする必要
> が出てきたために、0を埋めて利用するというような場合、別の配列
> を作ってコピーしたり、他の開発者にszからcに変更するように要求
> することまでする必要があるのだろうかとか、悩んでしまいます。

それは当然「そうまでする必要がある」でしょう。だっ
て、ハンガリアン記法を使う最大のメリットはデータの
名前から型や操作方法が確定することですもん。

もちろんなんでもかんでも確定するわけではないですけ
ど、確定するものについては厳然と確定する。szと書い
てあれば'\0'の終端は必ず存在するし、それ以降のデー
タについてはまったく気にしなくてよい。あらかじめそ
う決めておくことで、プログラミングやデバッグにおけ
るもろもろの問題を単純化できるわけです。

複数の人間で開発を行っているときに、インターフェー
スとして使っているデータで「szと書いてあるけど終端
がないかもしれないので自分でチェックしなければなら
ない」のようなローカルルールを追加したとしたら、ハ
ンガリアン記法によって得られるメリットのほとんどは
帳消しになってしまいますよね。

> んー、なら、
> union{
> char szTemp[512];
> char cTemp[512];
> };
> とかすればいいのかなぁ。

それだけではだめで、
(a) そのデータの本来の型(と名前)を決めておく。その
型(と名前)でそのデータにアクセスする人はハンガ
リアン記法のメリットをそのまま享受してよい
(b) そのデータのエーリアスに別の型(と名前)でアクセ
スしたい人は自分でエーリアスを管理し、アクセス
の入口と出口では本来の型(と名前)によるアクセス
に不整合が起きないように手当てを行う
のようなルールを決めておく必要があるでしょうね。

上の例ならデータは
char szTemp[512];
と定義しておき、「特殊なソート」を行う人は
(1) szTempに対するエーリアスcTempを作る
(2) cTempを初期化する(szTempとして見たときのの終端
以降を'\0'で埋める)
(3) cTempに対して「特殊なソート」を行う
(4) 結果がszTempとして正常であるようにcTempの後始
末をする
ぐらいはしなければいけないでしょう。

[YOSHIMOTO Hideyuki]

oh...@src.ricoh.co.jp (Junn Ohta) writes:

吉本＠元記事です。

非常に説明不足でしたね。すみません。
言いたかったことは

> 接頭辞szから、この配列にはASCIZ文字列しか格納され
> ないことが明白なので、先頭から見ていって最初に'\0'
> が出現する位置以降に何かを書き込むのは無意味です。
> 初期化したいのなら
> *szTemp = '\0'
> で必要十分でしょう。

これです。

文字列として扱うバッファをわざわざ全部'\0'クリアする
必要は無いですよね。
（文字列以外の処理の場合、0クリアはありえる処理ですが）

個人的には、「memsetで'\0'で初期化されている前提で行う
文字列処理」はあまりいただけないスタイルだと思います。

前に、
「ここの文字列処理、最後に\0つけてないよ」
「大丈夫です、memsetでクリアしてありますし」
というやり取りを行ったことがあるのですが、
そのような前提で処理をするのは問題があるんじゃないか？
さらに、あとからszTempが配列じゃなくて ポインタになったら
面倒じゃないの？

と思った次第です。

[Hisao Aoyama]

oh...@src.ricoh.co.jp (Junn Ohta) writes:

> > もちろん，2 と 3 はポインターが偶然正しそうなところを
> > 指していた場合は，実際は誤りでも検出できません．
>
> というか、検出できる場面のほうが圧倒的に少ないので
> はないですか?

多いか少ないかという場合，感覚的なものもあるので議論には
ならないかもしれませんが，とりあえず↓くらいは検出できま
す．

------8<------8<------8<------8<------8<------8<------8<------8<
1 -> load_header stdlib.h
Loading: -I. /tmp/OC.2ad4/stdlib.h
2 -> static char buf[128];
3 -> int main()
4 +> {
5 +> char *p = malloc(4);
6 +> char *q = (char *)0x1b6800;
7 +> char buf2[32];
8 +>
9 +> p += 10;
10 +> printf("%d\n", *p);
11 +> printf("%d\n", *q);
12 +> printf("%d\n", *(buf + 130));
13 +> printf("%d\n", buf2[32]);
14 +> }
15 -> run
Executing: a.out

----------------
"workspace":9, main(), Storing bad pointer (Warning #26)
Storing a bad pointer at auto variable main`p.
The pointer contains the value 0x1b662a.
General options: break/continue/quit/edit/reload

----------------
"workspace":10, main(), Dereference (Error #165)
Dereferencing a pointer ( p ) that is out of bounds.
Pointer previously pointed to allocated data.
Pointer went bad on line 9 in function 'main'.
Pointer = 0x1b662a, low bound = 0x1b6620, high bound = 0x1b6624.
General options: break/continue/quit/edit/reload
12

----------------
"workspace":11, main(), Dereference (Error #165)
Dereferencing a pointer ( q ) that is out of bounds.
Pointer = 0x1b6800, low bound = 0x0, high bound = 0x0.
General options: break/continue/quit/edit/reload
0

----------------
"workspace":12, main(), Dereference (Error #165)
Dereferencing a pointer that is out of bounds.
Pointer previously pointed to variable buf.
Pointer = 0x1e435a, low bound = 0x1e42d8, high bound = 0x1e4358.
General options: break/continue/quit/edit/reload
-65

----------------
"workspace":13, main(), Array index (Error #166)
Illegal array index 32 into auto variable main`buf2. Maximum array index is 31.
General options: break/continue/quit/edit/reload
-65
Program exiting with return status = 0.

Resetting to top level.
16 ->
------8<------8<------8<------8<------8<------8<------8<------8<

----
Hisao Aoyama 青山 尚夫
ASTEC Products, Inc. （株）アステック・プロダクツ
aoy...@astec.co.jp

[KATAYAMA Yoshio]

In article <9p1hsv$2h0u$1...@news2.rim.or.jp>,
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:

>> そういうあなたに calloc()。

> 7.20.3.1 The calloc function

> Note that this need not be the same as the representation
> of floating-point zero or a null pointer constant.

>とありますけど, 問題ないんでしょうか.

でした。(_ _;;;
--
片山＠ＰＦＵ

[Junn Ohta]

fj.comp.lang.cの記事<v4eloof...@astec.co.jp>で
aoy...@astec.co.jpさんは書きました。

> 多いか少ないかという場合，感覚的なものもあるので議論には
> ならないかもしれませんが，とりあえず↓くらいは検出できま
> す．

なるほど、わりと検出できるんですね。感覚的な揺れを
考慮しても「少ない」は間違いでした。

> 6 +> char *q = (char *)0x1b6800;

> ...

> 11 +> printf("%d\n", *q);

> ...

> "workspace":11, main(), Dereference (Error #165)
> Dereferencing a pointer ( q ) that is out of bounds.
> Pointer = 0x1b6800, low bound = 0x0, high bound = 0x0.

これが「だめ」というのはちょっと出しゃばりすぎかも。
つまりポインターをバイトデータにキャストして、ふた
たびポインターにキャストして使おうとしてもこのエラ
ーは出るんですよね? だとするとファームウエア寄りの
処理などはやりにくいかな。

[KATAYAMA Yoshio]

In article <9p7rt8$144p$1...@news1.wakwak.com>,
Takasuka Yoshihiro <tes...@bc.wakwak.com> writes:

>ただの揚げ足とりですが、szTemp をハンガリアン記法の ASCIIZ文字列と推論
>するとしても太田さんの言うとおり、
>*szTemp='\0'
>だけでいいかっていうと、
>UNICODE文字列とかの場合は、2byte連続の'\0'が終端記号になってたりするん

「2byte連続の'\0'が終端記号」になることはありません。

「UNICODE文字列」が UCS-2 のつもりなら、1 byte（C 言語の byte で
はなく、不可分のビット列の意味です）は 2 octet（16 bit）ですから、
そもそも char 型配列に格納することが間違っています。
--
片山＠ＰＦＵ

[Masao Seki]

関＠神奈川です。

Junn Ohta wrote in : <9p7chk$h72$1...@ns.src.ricoh.co.jp>
・
・
> ネタ配給元の別所さんが恐縮される必要はないです。こ
> こに出てきている人たちはみなそれなりに議論を楽しん
> でいるのですから。

私の場合、楽しむまでの余裕は中々持てませんが（半分
位は楽しんでいるかな？）、何とか、山を賑わす枯れ木の
一本にでもなれればと思って、且つ分相応のテーマを選ん
で時折投稿しております。
別所さんは、恐縮する必要がない所か、山を賑わすきっか
けを作ったと云う事で、（ひそかに）胸を張って良いと
思います。

> そのとおりなんですけど、これは初心者がとくに陥りや
> すい問題なので、どうして「これで確保できたはず」と
> 思い込んでしまったのか、というあたりに議論に参加し
> ている面々の興味が集中しているわけです。

それと、指摘が的を得た、的確な内容/形式を備えている
か、また指摘の手順は適切かetcについてですね。

> 「違います」という発言はそのあたりを見越したうえで
> 「確保したつもり」が間違っているのだということを指
> 摘しているわけですが、そういう指摘のしかたを好まな
> い人もいて、別のルートをたどろうとしているのですね。

私なら、別所さんの

別所さん> 先のエラーの原因は、
別所さん> 構造体を宣言した時に
別所さん> 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
別所さん> 「構造体のデータ本体を置く領域」は確保できていなかったということでしょうか？

と云う問いかけに対してYes or No で答えるなら

| その通りです。そもそも「構造体のデータ本体を置く
| 領域」を確保する行為を行っておられませんから、
| 確保できようがありません。

と答えていたと思います。と云う訳で、「違います」で
始まる回答に違和感を感じる所は、電子のお針箱さんの
感覚に近いものがあります。

でも、「違う」のか「その通り」なのかは、私には枝葉
末節の議論で、そもそもコアを吐いた事と領域の確保を
関連づけた質問に、Yes or Noで答える事は、初心者を
相手にした答えとしては、すでに焦点を外していると思
われるのですが、如何なものでしょうか。

okabeさんへの直接のフォローで、「ポインタに適切な
データが格納されていなかったから」と指摘するべきで
ないかと云う主張を述べさせて頂きましたが、回答は
これに尽きると思います。

コアを吐かないだけなら、ユーザのwritableなデータ
領域が充分な広さを持っていて、ポインタがたまたま
その途中の何処かを指していても （ポインタ操作に
関連する二次障害がなければ）吐かない訳ですから、
プログラマの責任で、適切なポインタデータを格納し
なければならない事こそ、強調されるべきだと思いま
す。

--
関＠神奈川
Masao Seki <ma-...@gb3.so-net.ne.jp>

[Kazuo Fox Dohzono]

In article <9p6l23$pko$2...@news01cg.so-net.ne.jp>
"Yoshiki Kataoka" <kat...@ka2.so-net.ne.jp> writes:

> # ところで
> # void *p, f(void **), g(void *);
> # f(&p);
> # で「これはいいの」って警告出ましたっけ？
> # g(p);
> # ならともかく

『「これはいいの」って警告』というのがよくわかりませんが,

warning: `p' might be used uninitialized in this function

のことなら g(p) はともかく f(&p) で出るのは変です.

--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp

[OGAWA Kunihiko]

小川です。
話が memset から流れているので、どこまでそれを
考えていいのかよくわからなくなったので確認させてください。

In article <15215.10...@insigna.ie.u-ryukyu.ac.jp>
at Fri, 28 Sep 2001 11:22:51 +0900

ko...@ie.u-ryukyu.ac.jp (Shinji KONO) さん wrote:

>でも、構造体を malloc したあと zero clear するのは、もはや、
>必須のようですね。へたに正しいポインタが残っていたりしますから。

これって、
memset(構造体へのポインタ, 0, 構造体サイズ);
のことを指しているのでしょうか?

In article <KATE.01Se...@flash.tokyo.pfu.co.jp>
at Fri, 28 Sep 2001 18:16:22 +0900
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) さん wrote:

>そういうあなたに calloc()。

In article <9p1hsv$2h0u$1...@news2.rim.or.jp>
at Fri, 28 Sep 2001 18:59:16 +0900
doh...@hf.rim.or.jp (Kazuo Fox Dohzono) さん wrote:

> 7.20.3.1 The calloc function
>
>の注釈に

>
> Note that this need not be the same as the representation
> of floating-point zero or a null pointer constant.
>
>とありますけど, 問題ないんでしょうか.

とすると、memset でゼロクリアするのも同じ理由でまずい気がするんですが。

・NULL を書くべき正しい場所に 0 を書いても正しい。
・しかし、NULL を表現するビットパターンは、全ビットが 0 とは限らない。
・浮動小数点表現のゼロのビットパターンも、全ビットが 0 とは限らない。

というあたりまでは理解しているつもりです。

・でも、きっとこれでも Windows や UNIX では問題なく動いてしまうだろう。

という気はします。

--
小川邦彦 <ku...@urawa.red-diamonds.net> <ku...@edit.ne.jp>

[Kazuo Fox Dohzono]

In article <KATE.01O...@flash.tokyo.pfu.co.jp>
ka...@pfu.fujitsu.com (KATAYAMA Yoshio) writes:

> > Note that this need not be the same as the representation
> > of floating-point zero or a null pointer constant.
>
> >とありますけど, 問題ないんでしょうか.
>
> でした。

各メンバに一々代入するのが嫌なら Compound Literals (C99) を使って

struct _foo_t *
foo_alloc (size_t nelm)
{
struct _foo_t *p = malloc (nelm * sizeof *p);
if (p)
{
while (nelm--)
p[nelm] = (struct _foo_t) {};
}
return p;
}

と書けると思うんですが, どうでしょうか.

[MAEDA Atusi (前田敦司)]

Takasuka Yoshihiro <tes...@bc.wakwak.com> writes:

> ># ASCIIZでなく、ASCIZじゃなかったっけ？どっちでも良いかな。(^^;
>
> どっちでしたっけ、自分ではなんとなく ASCIIZ って昔から書いてたんですが、
> 確認した事一度も無いです。

ASCIZ です。DEC系のアセンブラの疑似命令 .asciz が語源だと思います。

前田敦司

[電子のお針箱]

Junn Ohta <oh...@src.ricoh.co.jp> wrote in message

news:9p7chk$h72$1...@ns.src.ricoh.co.jp...

> > 分かりにくい書き方をしてしまって申し訳ありません。
> > 結局、この辺りの齟齬の大元は私の間違いからきてるので論争にされると心苦し
> > いですが....
>
> ネタ配給元の別所さんが恐縮される必要はないです。こ
> こに出てきている人たちはみなそれなりに議論を楽しん
> でいるのですから。

そうですね。まあ、別所さんにしてみれば「ちょっとしたミス」を延々議論されて
いるのでちょっと嫌かもしれませんね。申し訳ありませんが、あまり気にしないで下
されば幸いです。

> > 私の個人的背景無しにプログラムをみれば、単に「していない」ということにな

> > ります
>
> そのとおりなんですけど、これは初心者がとくに陥りや
> すい問題なので、どうして「これで確保できたはず」と
> 思い込んでしまったのか、というあたりに議論に参加し
> ている面々の興味が集中しているわけです。
>
> 「違います」という発言はそのあたりを見越したうえで
> 「確保したつもり」が間違っているのだということを指
> 摘しているわけですが、そういう指摘のしかたを好まな
> い人もいて、別のルートをたどろうとしているのですね。

まあ、岡部さんの...

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message

news:86elotss...@hgc02147.nifty.ne.jp...

> 「構造体のデータ本体を置く領域」を確保していなかった。

と言う意見は、もちろん正しいのですけど。別所さんの...

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:

> 先のエラーの原因は、
> 構造体を宣言した時に
> 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
> 「構造体のデータ本体を置く領域」は確保できていなかったということでしょう
> か ？

と言う認識で、別段問題ないであろうと思っています。

> 別所さんも、これらの議論を眺めて各人がどういうスタ
> ンスで発言しているのかを理解すれば、今後のC言語の
> 習得に役立つのではないかと思います。

う～～～ん、C言語の習得に役立つかなぁ...。まあ、世の中色々な考え方をする人
がいると言うことは、覚えておいて損はないですね。(^_^)

[電子のお針箱]

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
news:9p7rjc$2sen$1...@nwall1.odn.ne.jp...

> 処理系によって定義は異なりますが、例え0に定義されていても、
> NULLは空ポインタ定数なので、これはどんな場合でもマズイです。
> # NULLとNULは違いますし、バグらなければ良いという話でもない。
>
> 参考
> 「CプログラミングFAQ」(ISBN4-8101-8097-2)
> の5.9より一部抜粋。
>
> 　ポインタが必要なところでのみNULLと0は同等である。NULLを、
> ポインタ以外の0が必要な場面に使ってはならない。プログラム
> は動くかもしれないが、コンパイラに間違ったメッセージを送っ
> ていることに違いはない(ANSIはNULLの定義に(void *)0を使うこ
> とを許している。この場合ポインタ以外が必要な場合は全然うま
> くいかない)。とくにASCIIのヌル文字(NUL)が必要な場合は、
> 絶対にNULLを使ってはならない。慣例的表現の定数が必要なら自分で
> ▲▲▲▲▲▲▲▲▲▲▲▲▲▲
>
> #define NUL '\0'
>
> を用意すること。

どんな環境かわからないと言うのに、「どんな場合でも FAQ に従わないといけな
い」と言う主張ですね。

以前の貴方の発言...

Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
news:9p5mds$236c$1...@nwall1.odn.ne.jp...

> 背景となる環境・条件・目的がわからないと何ともいえないと思います。

と矛盾しますよ。

[電子のお針箱]

Junn Ohta <oh...@src.ricoh.co.jp> wrote in message

news:9p7ah0$ghb$2...@ns.src.ricoh.co.jp...

> 「違います」は
> > > 「構造体のデータ本体を置く領域」は確保できていなかった
> 「と言う事実」に対するものではなくて、文章全体に対
> する答えでしょう。それは岡部さんのその後の文章から
> も明らかだと思います。

ふむ、なるほど...

BESSHO Tomohiro <t_be...@a2.sci.ne.jp> writes:

> 先のエラーの原因は、
> 構造体を宣言した時に
> 「構造体のデータ領域を示すポインタを置く領域」は確保できていても
> 「構造体のデータ本体を置く領域」は確保できていなかったということでしょう
> か ？

確かに、「構造体を宣言した時に」と書いてあるので...

> struct bin{
> char name[30];
> int quantity;
> int cost;
> };

に、よって...

> 「構造体のデータ領域を示すポインタを置く領域」は確保できて

という文章は「誤って」います。<--[A]

でも、岡部さんは...

okabe katsuyuki <hgc0...@nifty.ne.jp> wrote in message

news:86n13d9m...@hgc02147.nifty.ne.jp...

> 「してない」と「できない」って同じ意味なんでしょうか？

と言うように、[A] を問題にしているのではなく...

> struct bin *cola;

によって、「構造体のデータ本体を置く領域」を...

(1) 確保できていなかった
(2) 確保していなかった

を問題にしていると思います。

そう言う意味において、(1) が「間違っている」とは言えないのではないですか ?

# 「両方正しい。」が正解と思います。

[Junn Ohta]

fj.comp.lang.cの記事<3BB8360E...@gb3.so-net.ne.jp>で
ma-...@gb3.so-net.ne.jpさんは書きました。

> でも、「違う」のか「その通り」なのかは、私には枝葉
> 末節の議論で、そもそもコアを吐いた事と領域の確保を
> 関連づけた質問に、Yes or Noで答える事は、初心者を
> 相手にした答えとしては、すでに焦点を外していると思
> われるのですが、如何なものでしょうか。

その場で唯一絶対の立場にある人間の発言ならともかく、
ネットニューズという場ではむしろ
・根拠があるならYes or Noで明快に答える
・Yes or Noにより誤読を招く可能性があるなら適切な
フォローを行う
といった手順のほうが適切であると思っています。よう
するに個々人の立場を明確にした発言がなされたほうが
読者にとってのメリットが大きいということです。

もっと具体的にいうと、その発言に対して別の人が反論
するときにも立場が明解になりやすく、元の質問をした
人が発言の比較検討を行いやすいってことですね。

初心者であろうとなかろうと、原則として他人の文章を
理解するだけの能力がある人間であれば、Yes or Noと
言い切ることによるデメリットはそれほど心配しなくて
いいだろうと私は考えます。

> okabeさんへの直接のフォローで、「ポインタに適切な
> データが格納されていなかったから」と指摘するべきで
> ないかと云う主張を述べさせて頂きましたが、回答は
> これに尽きると思います。

もちろんそう思う人がそのようにフォローすればいいの
です。Yes or Noはそのようなフォローを行う邪魔にな
るわけではないでしょう?

[Junn Ohta]

fj.comp.lang.cの記事<9p9ros$iu3$4...@newsjp.mbn.or.jp>で
ueno-...@di.mbn.or.jpさんは書きました。

> 確かに、「構造体を宣言した時に」と書いてあるので...
> > struct bin{
> > char name[30];
> > int quantity;
> > int cost;
> > };

岡部さんはこのコードで「構造体を宣言した」と考えて
いるのではないでしょう。むしろ

> > struct bin *cola;

で「構造体を宣言した」と考えていて、つまり宣言と定
義をごっちゃにしていて、しかもポインターの理解が不
足していることによって、コードも正しく書けなかった
し、質問の文章も粗いものになっていた、と。

> > struct bin *cola;
> によって、「構造体のデータ本体を置く領域」を...
> (1) 確保できていなかった
> (2) 確保していなかった
> を問題にしている

違うでしょう。岡部さんはむしろ

> > struct bin *cola;

で
(a) 構造体を宣言(定義)した
(b) データ本体を置く領域を確保した
の両方を行ったつもりだったわけです。

そのこと全体は「正しい」とはいえませんし、「違いま
す」が妥当な答えであるという理由もそこにあります。

[S.Masa]

S.Masa です．

"okabe katsuyuki" wrote
<864rpm6w...@hgc02147.nifty.ne.jp>
about "Re: Re[2]: 構造体のポインタ演算子のエラー"
on 29 Sep 2001 21:03:50 +0900

>この場合だと、memset(szTemp, NULL, sizeof(szTemp)); は
>
>for (i = 0; i < sizeof(szTemp); i++) {
> szTemp[i] = NULL;
>}
>
>と同義なんですけど、どこがおかしいのかわかりませんか？

はい，分かりません．
どこがおかしいのですか？

char szTemp で 512 個の char 配列を確保．
sizeof(szTemp) でもちゃんと 512 と返るはずだし．．．．
アクセスできる配列の要素もちゃんとまもってるはずです．
なにがおかしいのですか？

2001/10/01(Mon) 11:36:09
--
Word by Ｓ．Ｍａｓａ
masa.s...@nifty.ne.jp
http://homepage2.nifty.com/DSS/

[S.Masa]

S.Masa です．

"Junn Ohta" wrote
<9p4l1i$l07$1...@ns.src.ricoh.co.jp>

about "Re: Re[2]: 構造体のポインタ演算子のエラー"

on 29 Sep 2001 14:15:14 GMT

>接頭辞szから、この配列にはASCIZ文字列しか格納され

（ハンガリアン記法なんでしょうけど）
ハンガリアン記法じゃないかもしれないです．
っていうか，
文字列を代入したとしても，それを文字列として扱わないといけないってこと
もないでしょう．
文字列ならば最後に '\0' が必要ってだけで，char の配列なんですから．

2001/10/01(Mon) 11:39:02

[Shin-ichi TSURUTA]

電子のお針箱さん、こんにちは、鶴田(SYN)です。

電子のお針箱 <ueno-...@di.mbn.or.jp> wrote:
> Shin-ichi TSURUTA <syn...@pop21.odn.ne.jp> wrote in message
> news:9p7rjc$2sen$1...@nwall1.odn.ne.jp...
>
> > 処理系によって定義は異なりますが、例え0に定義されていても、
> > NULLは空ポインタ定数なので、これはどんな場合でもマズイです。
> > # NULLとNULは違いますし、バグらなければ良いという話でもない。
> >
> > 参考
> > 「CプログラミングFAQ」(ISBN4-8101-8097-2)
> > の5.9より一部抜粋。
> >
> > 　ポインタが必要なところでのみNULLと0は同等である。NULLを、
> > ポインタ以外の0が必要な場面に使ってはならない。プログラム
> > は動くかもしれないが、コンパイラに間違ったメッセージを送っ
> > ていることに違いはない(ANSIはNULLの定義に(void *)0を使うこ
> > とを許している。この場合ポインタ以外が必要な場合は全然うま
> > くいかない)。とくにASCIIのヌル文字(NUL)が必要な場合は、
> > 絶対にNULLを使ってはならない。慣例的表現の定数が必要なら自分で
> > ▲▲▲▲▲▲▲▲▲▲▲▲▲▲
> >
> > #define NUL '\0'
> >
> > を用意すること。
>
> どんな環境かわからないと言うのに、「どんな場合でも FAQ に従わないといけな
> い」と言う主張ですね。

いいえ。そこまで主張するつもりはありません。が、この話がその
ようにしか思えない人は、それはそれでいいと思いますよ～♪

[Shin-ichi TSURUTA]

Junn Ohtaさん、こんにちは、鶴田(SYN)です。

oh...@src.ricoh.co.jp (Junn Ohta) wrote:
> fj.comp.lang.cの記事<9p86c8$1emu$1...@nwall2.odn.ne.jp>で
> syn...@pop21.odn.ne.jpさんは書きました。
> > ただ、複数の人間で開発していて、自分以外の開発者がその構造体
> > にアクセスする場合は完全にASCIZ文字列であり、終端以降を気に
> > する必要はないのだが、自分のルーチンであとからソートする必要
> > が出てきたために、0を埋めて利用するというような場合、別の配列
> > を作ってコピーしたり、他の開発者にszからcに変更するように要求
> > することまでする必要があるのだろうかとか、悩んでしまいます。
>
> それは当然「そうまでする必要がある」でしょう。だっ
> て、ハンガリアン記法を使う最大のメリットはデータの
> 名前から型や操作方法が確定することですもん。

まぁ、そうなのですが、自分の中で閉じているところまで、厳密に
そうする必要があるかどうかというと、ちょっと疑問です。

> もちろんなんでもかんでも確定するわけではないですけ
> ど、確定するものについては厳然と確定する。szと書い
> てあれば'\0'の終端は必ず存在するし、それ以降のデー
> タについてはまったく気にしなくてよい。あらかじめそ
> う決めておくことで、プログラミングやデバッグにおけ
> るもろもろの問題を単純化できるわけです。
>
> 複数の人間で開発を行っているときに、インターフェー
> スとして使っているデータで「szと書いてあるけど終端
> がないかもしれないので自分でチェックしなければなら
> ない」のようなローカルルールを追加したとしたら、ハ
> ンガリアン記法によって得られるメリットのほとんどは
> 帳消しになってしまいますよね。

ええ、まったくもってそうなのですが、一応外部からは完全にASCIZ
として扱えることを想定しています。

> > んー、なら、
> > union{
> > char szTemp[512];
> > char cTemp[512];
> > };
> > とかすればいいのかなぁ。
>
> それだけではだめで、
> (a) そのデータの本来の型(と名前)を決めておく。その
> 型(と名前)でそのデータにアクセスする人はハンガ
> リアン記法のメリットをそのまま享受してよい
> (b) そのデータのエーリアスに別の型(と名前)でアクセ
> スしたい人は自分でエーリアスを管理し、アクセス
> の入口と出口では本来の型(と名前)によるアクセス
> に不整合が起きないように手当てを行う
> のようなルールを決めておく必要があるでしょうね。
>
> 上の例ならデータは
> char szTemp[512];
> と定義しておき、「特殊なソート」を行う人は
> (1) szTempに対するエーリアスcTempを作る
> (2) cTempを初期化する(szTempとして見たときのの終端
> 以降を'\0'で埋める)
> (3) cTempに対して「特殊なソート」を行う
> (4) 結果がszTempとして正常であるようにcTempの後始
> 末をする
> ぐらいはしなければいけないでしょう。

処理については同感です。自分のコードの中なら、エイリアスを作
るまでしなくても、コメントを書いておくくらいじゃダメかなぁ…。

[Junn Ohta]

fj.comp.lang.cの記事<20011001113903.C...@nifty.ne.jp>で
masa.s...@nifty.ne.jpさんは書きました。
> （ハンガリアン記法なんでしょうけど）
> ハンガリアン記法じゃないかもしれないです．

ハンガリアン記法でなければあの文章には何の教訓もな
い(NULLの件は除く)ので、わざわざそう解釈して「おか
しいところはないはず」と主張しても意味ないです。:-)

> っていうか，
> 文字列を代入したとしても，それを文字列として扱わないといけないってこと
> もないでしょう．

いや、「文字列として扱わないといけない」という点こ
そがハンガリアン記法の強力さにつながるわけです。そ
こが理解できてないのではないですか?

あの文章は、そういうハンガリアン記法の意義を理解し
て、そのうえでそれを選択して使っているはずなのに、
どこをどう間違ったかトチくるった使いかたをしてしま
ったところが見苦しい、という話なんです。

[okabe katsuyuki]

岡部です。

S.Masa <masa.s...@nifty.ne.jp> writes:

> >for (i = 0; i < sizeof(szTemp); i++) {
> > szTemp[i] = NULL;
> >}
> >
> >と同義なんですけど、どこがおかしいのかわかりませんか？
>
> はい，分かりません．
> どこがおかしいのですか？

ANSI Cが前提だとすると、NULLはポインタです。
対してszTemp[i]の型はcharです。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[okabe katsuyuki]

岡部です。

私は、別所さんが

struct bin *cola;

で、

(1) 「構造体のデータ領域を示すポインタを置く領域」を確保した
(2) 「構造体のデータ本体を置く領域」を確保した、けどできなかった

と考えられていると思いましたので、(1)はともかく(2)については確保すると
いう行為を行っていませんから「違います」「できるできない以前に確保する
行為を行っていません」という回答をしました。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[okabe katsuyuki]

岡部です。

oh...@src.ricoh.co.jp (Junn Ohta) writes:

> 岡部さんはこのコードで「構造体を宣言した」と考えて
> いるのではないでしょう。むしろ

(snip)

とりあえず質問したのは私ではありません(^^;

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[Shigehiko SASAKI]

佐々木@でかいの です。

関さん

> コアを吐かないだけなら、ユーザのwritableなデータ
> 領域が充分な広さを持っていて、ポインタがたまたま
> その途中の何処かを指していても （ポインタ操作に
> 関連する二次障害がなければ）吐かない訳ですから、

最初の質問をされた別所さんのケースは、以下の投稿から察するに
関さんが言われたような「たまたまwritableな領域を指していた」
だったと思われます。

別所さん
> 一応、gdbを使ってはいます。（マニュアルめくりながらなんで、使いこなし
> てるとは言い難いですが）
> 今回の場合、全ての処理が終ってから（「return 0;」 も終ってから）
> 「from /lib/libc.so.6」とか書かれたエラーを出してるので
> 「なんじゃこりゃ」とおもったわけでして（ <- gdb が使いこなせていないから？ ）

問題のソースコード
> int main()
> {
> struct bin *cola;
>
> (void) strcpy( cola->name, "No.1 juice");
> (void) printf("property :%s \n", cola->name);
>
> return 0;
> }

おそらく colaには、スタックの一部を指すアドレスが入っていて
不正にスタックを破壊してしまったんではないでしょうか?
スタックは当然書込可能領域ですから、そのときは例外は発生しません。
return でmain()を抜けた後、後処理部でスタックが破壊されていたために
例外が発生したものと思われます。

gccで-Oオプションをつけていないと、自動変数の暗黙のレジスタ割当ては
行いませんから、前の関数の自動変数の内容が残っていたりします。

int i; を struct bin *cola; の前にいれると、自動変数の割当アドレスが
ずれて、たまたま問題が起きない(ように見える)アドレスが colaに
入ったのでしょう。

でかいの企画 佐々木茂彦
ssa...@dekaino.net

[Junn Ohta]

fj.comp.lang.cの記事<86669zb...@hgc02147.nifty.ne.jp>で
hgc0...@nifty.ne.jpさんは書きました。
> とりあえず質問したのは私ではありません(^^;

おっと、すみません。(_ _;

[Hoshi Takanori]

ほしです。ちゃちゃです。しかも偏見入ってます。

In article <9pa7vs$ela$1...@ns.src.ricoh.co.jp>
oh...@src.ricoh.co.jp (Junn Ohta) writes:

> いや、「文字列として扱わないといけない」という点こ
> そがハンガリアン記法の強力さにつながるわけです。そ
> こが理解できてないのではないですか?
>
> あの文章は、そういうハンガリアン記法の意義を理解し
> て、そのうえでそれを選択して使っているはずなのに、
> どこをどう間違ったかトチくるった使いかたをしてしま
> ったところが見苦しい、という話なんです。

この議論を斜め読みしてると、「ハンガリアン記法の意義」を
理解して、正しく使わなきゃと言ってる人ほど、実際には
使ってないような気がするんですが...

＃ 結局、規則を厳密に適用しなきゃ気が済まない人には、
＃ 息苦しくって使えない、ってことなのかなぁ...

ほし＠もちろん、わたしも使ってません。

[Junn Ohta]

fj.comp.lang.cの記事<HOSHI.01O...@ext54.sra.co.jp>で
ho...@sra.co.jpさんは書きました。

> この議論を斜め読みしてると、「ハンガリアン記法の意義」を
> 理解して、正しく使わなきゃと言ってる人ほど、実際には
> 使ってないような気がするんですが...

いや、「正しく使わなきゃ」と言っていて、しかも実際
に使っている人はそれなりに多いです。たんにそういう
人たちはネットニューズなんて読まないのだけのことで
しょう。:-)

> ＃ 結局、規則を厳密に適用しなきゃ気が済まない人には、
> ＃ 息苦しくって使えない、ってことなのかなぁ...

多人数で開発するときは、いずれにしても何らかの「息
苦しい」規則が必要ですから、べつにハンガリアン記法
がそのせいで嫌われるということはないと思いますよ。
その発想そのものにあまり共感が得られていないだけな
のではないかと。

[Narita Takaoki]

成田です。

<HOSHI.01O...@ext54.sra.co.jp>の記事において
ho...@sra.co.jpさんは書きました。

> ほしです。ちゃちゃです。しかも偏見入ってます。

私も偏見入れます。(^^;

> In article <9pa7vs$ela$1...@ns.src.ricoh.co.jp>
> oh...@src.ricoh.co.jp (Junn Ohta) writes:
>
> > いや、「文字列として扱わないといけない」という点こ
> > そがハンガリアン記法の強力さにつながるわけです。そ
> > こが理解できてないのではないですか?

:

> この議論を斜め読みしてると、「ハンガリアン記法の意義」を
> 理解して、正しく使わなきゃと言ってる人ほど、実際には
> 使ってないような気がするんですが...
>
> ＃ 結局、規則を厳密に適用しなきゃ気が済まない人には、
> ＃ 息苦しくって使えない、ってことなのかなぁ...

いっそ、コンパイラが関数や変数の表記までチェックしてくれて、使い
方に関してまでは叱ってくれなくてもよいけれど、型に対しイリーガル
な変数名とかにしたら、叱ってくれれば良いのに、とか考えたり。

# 以前、Smalltalk の ML で似た様な事を書いてポストしたら、既にそ
# ういう代物が存在したってのもあったので、C に関してもあるのかも
# しれないけれど。(^^;

> ほし＠もちろん、わたしも使ってません。

わたしなんか最近 C でプログラム書いてません。(^^;;;;

--
成田 隆興 ＠ エー・アイ・ソフト株式会社 NB 推進部
E-mail tak...@aisoft.co.jp
『十分間で決断し、短い理由を添えよ。』

[Kazuo Fox Dohzono]

In article <86bsjrb7...@hgc02147.nifty.ne.jp>
okabe katsuyuki <hgc0...@nifty.ne.jp> writes:

> ANSI Cが前提だとすると、NULLはポインタです。

「整数の 0 または void * にキャストされた 0」です.

[Kazuo Fox Dohzono]

In article <0110012036...@korosuke.edit.ne.jp>
OGAWA Kunihiko <ku...@urawa.red-diamonds.net> writes:

> とすると、memset でゼロクリアするのも同じ理由でまずい

ということになるでしょうね.

# struct sockaddr* の残りのシステムが使う部分は char [] で宣言されてる.

[Iwao Watanabe]

"Shin-ichi TSURUTA" <syn...@pop21.odn.ne.jp> wrote
in message news:9p7rjc$2sen$1...@nwall1.odn.ne.jp...
>

> #define NUL '\0'
>
> を用意すること。

Cでは表記こそ違えど　'\0' == 0 ですね。
評価する場合は必ずintになるので。

昔は　'\0' に　こだわっていましたが，今はもっぱら　0 です。

#　シフトキーを押すのが面倒になっちゃいました。

[Iwao Watanabe]

"Shinji KONO" <ko...@ie.u-ryukyu.ac.jp> wrote
in message news:15215.10...@insigna.ie.u-ryukyu.ac.jp...

>
> でも、構造体を malloc したあと zero clear するのは、もはや、
> 必須のようですね。へたに正しいポインタが残っていたりしますから。

規格で触れられている構造体のゼロクリアは、
staticで宣言された変数の値を代入することです。
だいぶ昔に同じ内容を述べた気がします。

{
static struct foo zero;
struct foo *bar;

bar = malloc(sizeof *bar);
*bar = zero; /* 初期化！ */
}

コンパイラが賢ければ、動作時にzeroは存在しないかもしれませんね。

別件で付いているフォローで紹介されている callocやmemsetは
動作しない処理系があるはずです。
#　昔、浮動少数点数やポインタではまった経験あり。

そういえばcfreeはlibcにはもう無いですね。
古いSunOSかなにかのマニュアルでは calloc と一緒に紹介されていた気がします。

[松本 洋暁]

松本です.

doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:

> > ANSI Cが前提だとすると、NULLはポインタです。
>
> 「整数の 0 または void * にキャストされた 0」です.

整数の 0 は処理系が変換しないといけないので岡部さんの方が簡潔だと思い
ますが.

--
======================//
Hiroaki Matsumoto // ze...@f5.dion.ne.jp
//======================

[Kazuo Fox Dohzono]

In article <uu1xif...@news.fin.ei.nsc.co.jp>

松本 洋暁<ze...@f5.dion.ne.jp> (Hiroaki Matsumoto) writes:

> > > ANSI Cが前提だとすると、NULLはポインタです。
> >
> > 「整数の 0 または void * にキャストされた 0」です.
>
> 整数の 0 は処理系が変換しないといけないので岡部さんの方が簡潔だと思い
> ますが.

# ((void *) 0) は処理系が変換しなくていいの? :-p

#define NULL 0 という処理系も ANSI C で認められているという指摘です.

An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
…
The macro NULL is defined in <stddef.h> as a null pointer constant

[OGAWA Kunihiko]

小川です。
本題とは外れますが

In article <9pbr9c$c92$2...@nwjp2.odn.ne.jp>
at Tue, 02 Oct 2001 16:39:53 +0900

iw...@DSL.gr.jp ("Iwao Watanabe") さん wrote:

>昔は　'\0' に　こだわっていましたが，今はもっぱら　0 です。
>#　シフトキーを押すのが面倒になっちゃいました。

101や104(ASCII)キーボードを使っていると、
'\0' と打つ時に一度もシフトキーは使いません。

ですが、4文字全部が右手小指なので打ちにくいことに
変わりはないです。

--
小川邦彦 <ku...@urawa.red-diamonds.net> <ku...@edit.ne.jp>

[Hideo Sir MaNMOS Morishita]

In article <0110021908...@korosuke.edit.ne.jp>,
OGAWA Kunihiko <ku...@urawa.red-diamonds.net> writes:
> 小川です。
> 本題とは外れますが

続くようなら

fj.comp.dev.keyboardかぁ？

> In article <9pbr9c$c92$2...@nwjp2.odn.ne.jp>
> at Tue, 02 Oct 2001 16:39:53 +0900
> iw...@DSL.gr.jp ("Iwao Watanabe") さん wrote:
>
> >昔は　'\0' に　こだわっていましたが，今はもっぱら　0 です。
> >#　シフトキーを押すのが面倒になっちゃいました。
>
> 101や104(ASCII)キーボードを使っていると、
> '\0' と打つ時に一度もシフトキーは使いません。
>
> ですが、4文字全部が右手小指なので打ちにくいことに
> 変わりはないです。

あ、私、0は薬指…変かなぁ。

--
___ わしは、山吹色のかすてーらが大好きでのぅ
[[o o]] ふぉっふぉっふぉ
'J' 森下 お代官様 ＭａＮＭＯＳ 英夫＠ステラクラフト
PGP Finger = CD EA D5 A8 AD B2 FE 7D 02 74 87 52 7C B7 39 37

[okabe katsuyuki]

岡部です。

doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:

> > ANSI Cが前提だとすると、NULLはポインタです。
>
> 「整数の 0 または void * にキャストされた 0」です.

NULLの型を整数と間違えないようにあえて「整数の0」とは書いていません。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[MAEDA Atusi (前田敦司)]

man...@stellar.co.jp (Hideo "Sir MaNMOS" Morishita) writes:

> > 101や104(ASCII)キーボードを使っていると、
> > '\0' と打つ時に一度もシフトキーは使いません。
> >
> > ですが、4文字全部が右手小指なので打ちにくいことに
> > 変わりはないです。
>
> あ、私、0は薬指…変かなぁ。

私が買ったタイピングの教則ソフトでは「0は薬指」となっていたと思います。
(7, 8が人指し指、9が中指。)

いま気づいた。私は、0は薬指で押すけど閉じカッコの時は0を中指で押してる！

前田敦司

[S.Masa]

S.Masa です．

"YOSHIMOTO Hideyuki" wrote
<usnd4q...@siren.ocn.ne.jp>

about "Re: Re[2]: 構造体のポインタ演算子のエラー"

on 01 Oct 2001 12:30:28 +0900

>文字列として扱うバッファをわざわざ全部'\0'クリアする
>必要は無いですよね。
>（文字列以外の処理の場合、0クリアはありえる処理ですが）

特異な場面ではあると思うんですが，"\0\0" を終端とする文字列もあります
よ．'\0' はセパレータで．
ファイルコモンダイアログに渡すものだったか，渡されるものだったか忘れま
したがファイル名の列挙でそういう形式もあります．
それは文字列として使っていますが，その場合全部が '\0' でセットされてい
ると便利ですよね？
ファイル名をずらずらと memset していくだけでいいんですから．
（終端の "\0\0" はきにしなくていいし）

2001/10/02(Tue) 11:46:17

[Masao Seki]

関＠神奈川です。

Junn Ohta wrote in: <9pa08c$cke$1...@ns.src.ricoh.co.jp>
>
> fj.comp.lang.cの記事<3BB8360E...@gb3.so-net.ne.jp>で
> ma-...@gb3.so-net.ne.jpさんは書きました。
・
・
> > でも、「違う」のか「その通り」なのかは、私には枝葉
> > 末節の議論で、そもそもコアを吐いた事と領域の確保を
> > 関連づけた質問に、Yes or Noで答える事は、初心者を
> > 相手にした答えとしては、すでに焦点を外していると思
> > われるのですが、如何なものでしょうか。
>
> その場で唯一絶対の立場にある人間の発言ならともかく、
> ネットニューズという場ではむしろ
> ・根拠があるならYes or Noで明快に答える
> ・Yes or Noにより誤読を招く可能性があるなら適切な
> フォローを行う
> といった手順のほうが適切であると思っています。よう
> するに個々人の立場を明確にした発言がなされたほうが
> 読者にとってのメリットが大きいということです。

一般論としては、全く異存がないのですが、今回の場合は
チョット違うのではと感じました。でも、今回のスレッド
全体を読み返してみて、少し自信が無くなって来ました。

キイは、Ｃ言語のポインタを利用するプログラムを初めて
記述しようとする方々が、何故かポインタ変数の宣言を
しただけで、本体の領域の確保と、その領域を参照する為
の、ポインタデータの格納が自動的にされてしまうと云う
錯覚に陥る現象に対して、本人の関心の在り方を踏まえた
上で、如何に回答すべきかと云う事だと思います。

私は、ポインタデータの格納は自動的には行われない事の
理解を重視する余り、ご本人の関心の在り方を、軽視しす
ぎていたかも知れないなと反省しております。

その為に、岡部さんと電子のお針箱さんの議論を枝葉末節
などと大変失礼な表現をしてしまい、お二人に不愉快な
思いをさせてしまったであろう事をお詫び致します。

int i; を加えただけで、現象が変わる理由については、
どなたも直接答えていなかった様ですが、佐々木@でかいの
さんが、適切な回答を示して下さいましたので、別所さん
の疑問はほぼ解けたかと思われますが、如何でしょうか。

# スタック領域を破壊する事の防止の仕組みが、何らかの
# 形で実現できていても良いように思えるのですが、素人
# の勝手すぎる要望でしょうか。
# In Line Assemblerを含むＣソースまでチェックしろと
# は、申しません。

--
関＠神奈川
Masao Seki <ma-...@gb3.so-net.ne.jp>

[Junn Ohta]

fj.comp.lang.cの記事<3BB9E3A7...@gb3.so-net.ne.jp>で
ma-...@gb3.so-net.ne.jpさんは書きました。

> 一般論としては、全く異存がないのですが、今回の場合は
> チョット違うのではと感じました。でも、今回のスレッド
> 全体を読み返してみて、少し自信が無くなって来ました。

自信をなくす必要はないのではないかと。私自身も関さ
んのような立場の発言が登場することを期待しているの
ですし、だからこそ私は私自身の立場で発言できるわけ
ですね。

> キイは、Ｃ言語のポインタを利用するプログラムを初めて
> 記述しようとする方々が、何故かポインタ変数の宣言を
> しただけで、本体の領域の確保と、その領域を参照する為
> の、ポインタデータの格納が自動的にされてしまうと云う
> 錯覚に陥る現象に対して、本人の関心の在り方を踏まえた
> 上で、如何に回答すべきかと云う事だと思います。

だからこそ、私も最初に短いヒントだけの記事を投稿し
たのです。あれは風向きの観測。:-)

[okabe katsuyuki]

岡部です。

Masao Seki <ma-...@gb3.so-net.ne.jp> writes:

> その為に、岡部さんと電子のお針箱さんの議論を枝葉末節
> などと大変失礼な表現をしてしまい、お二人に不愉快な
> 思いをさせてしまったであろう事をお詫び致します。

私はぜんぜんきにしてませんよ。

--
okabe katsuyuki <HGC0...@nifty.ne.jp>

[Kazuo Fox Dohzono]

In article <86vghyj...@hgc02147.nifty.ne.jp>
okabe katsuyuki <hgc0...@nifty.ne.jp> writes:

> NULLの型を整数と間違えないように

NULL の型は整数でもいいんですってば.