- PR -

32bit環境から64bit環境へのCプログラムの移植について

投稿者投稿内容
1co
常連さん
会議室デビュー日: 2005/08/10
投稿数: 39
投稿日時: 2007-06-17 23:52
こんばんは。

標記の件について、質問させてください。

32bit環境下で稼動していたCプログラムを64bit環境に移植したところ、
正常に動作しないケースが見受けられました。
当方運用担当で、Cプログラムの知識が皆無に等しく、
プログラムを作成した技術者も現在社内におりませんので、
32bitから64bitへの移植が原因かどうかもわかりませんが、
IBMのサイトなどを検索した結果、そこに問題があるのではないかという結果にたどり着きました。

不具合が発生したのは、プログラム中以下の箇所です。

コード:
void DCC_CutBirthDateMonth( char* pSrc, int* pMonth)
{
	char pDst[3];
    *pMonth = NULL;

 	    strncpy( pDst, &pSrc[4], 2);
		*pMonth = atoi( pDst);

    return;
}



pSrcとして渡ってきた'YYYYMMDD'形式の文字列から、
'MM'のみ抽出し、intに変換の上、pDstとして返却する、
という処理だと思うのですが、
300万件処理した結果300件ほど'MM'に不正な数値がセットされてしまいました。

ex.)
pSrc = '20070617'
pMonth = '62'

いろいろ調査はしているのですが、現在のところ不正なデータに規則性は認められません。

環境は、
AIX 5.3
XL C Enterprise Edition for AIX V8.0
です。
# 情報が不足しておりましたら、申し訳ございませんがご指摘ください。

どなたか解決方法をご存知の方がいらっしゃいましたら、ヒントでもかまいませんので、
ご教示いただければと思います。
よろしくお願いいたします。
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2007-06-18 00:11
なんと言うか、「今までは、たまたま上手く動いていた」だけです。
32ビットとか64ビットとかいう問題じゃない。

pDstの初期値は不定。
strncpyは、指定文字数一杯をコピーした場合は'\0'を付加しない。
pDstはNUL終端されていない文字列になるので、atoiの結果は保証できません。
1co
常連さん
会議室デビュー日: 2005/08/10
投稿数: 39
投稿日時: 2007-06-18 00:31
coasmさま

早々のご回答ありがとうございます。

では、対処方法としては、
@pDstの初期値を設定する。
Astrncopyした結果に'\\0'を付加。
でよろしいのでしょうか?

また、参考までに、今までなぜ「たまたま上手く動いていた」のか、
お教え願えませんでしょうか?

度々申し訳ございませんが、ご回答いただけますと幸いです。
よろしくお願いいたします。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2007-06-18 01:00
pSrc を検証しなくていいのかな?
_________________
1co
常連さん
会議室デビュー日: 2005/08/10
投稿数: 39
投稿日時: 2007-06-18 01:10
ちゃっぴさま

ご回答ありがとうございます。

ご指摘のとおり、pSrcを検証する必要もあるかと思います。
そもそも、pSrcが'YYYYMMDD'というフォーマットかどうかも未検証ですので。。

明日、出社後、早急に確認しようと思います。
情報・検証が不十分なまま投稿してしまい、申し訳ございません。
coasm
大ベテラン
会議室デビュー日: 2001/11/26
投稿数: 237
投稿日時: 2007-06-18 11:20
pDstを初期化していないと、たまたまその時点でメモリーに残っていたデータが
そのまま使われます。
atoi()は数字以外の文字に出会うと処理を終了するので、pDst[2]が'\0’でなくても、
数字以外の文字であれば、期待通りの動作をします。
つまり、pDst[2]に残っていたデータが数字であった場合だけ不具合が表面化し、
それ以外の場合は「たまたま上手く動く」わけです。
1co
常連さん
会議室デビュー日: 2005/08/10
投稿数: 39
投稿日時: 2007-06-18 13:57
coasmさま

ご回答ありがとうございます。

「たまたま動く」ケースのご説明、理解できました。

通常、1日30万件程度処理しておりましたが、そのときは全件「たまたま動いていた」ようです。
今回、移行作業の兼ね合いで、1週間分ほど(300万件)まとめて処理した結果、
動かないケースが現れましたので、件数の増加に伴い、
「たまたま動く」ケースが減ったのでしょうか・・・。

とにかく、ロジックを修正し、テストしてみます。
ちゃっぴさまからのご指摘もありますし、多方面から確認を試みたいと思います。
結果がわかり次第、再度投稿させていただきます。
1co
常連さん
会議室デビュー日: 2005/08/10
投稿数: 39
投稿日時: 2007-06-19 14:14
レスが大変遅くなりまして申し訳ございません。
(徹夜で作業しておりました。ご容赦いただけますと幸いです。)

coasmさまのご指摘どおり、strncopyした結果に'\\0'を付加する処理を追加の上再処理したところ、正常に動作いたしました。

また、ちゃっぴさまご指摘の、pSrcの検証については、
件数が膨大なため全件の確認には至っておりませんが、
現在のところ内容に不備のあるものは検出されておりません。
引き続き検証を続行するとともに、ほかにstrncpy使用箇所で
同様の不具合が予想される箇所の確認を急いでおります。

取り急ぎ、現状報告ですが、ご回答くださったみなさま、
ありがとうございました。
大変助かりました。

スキルアップ/キャリアアップ(JOB@IT)