プロが教えるわが家の防犯対策術!

reallocを使うとエラーがでます。
簡単なreallocのプログラムでもエラーがでて、realloc自体が使えないような感じです。
どうしたらよいでしょうか?
試したプログラムは

#include<stdlib.h>
#include<stdio.h>
#include<string.h>
int main(void){
char *p;
p=malloc(17);
if(!p){
printf("error\n");
exit(1);
}
strcpy(p,"これは16文字です");
p=realloc(p,18);
if(!p){
printf("error\n");
exit(1);
}
strcat(p,".");
printf(p);
free(p);
return 0;
}

というもので、

*** glibc detected *** ./test: realloc(): invalid next size: 0x09b61008 ***
======= Backtrace: =========
/lib/libc.so.6[0x43ca2f]
/lib/libc.so.6(realloc+0xfe)[0x43e68e]
/lib/libc.so.6[0x43ea61]
/lib/libc.so.6(realloc+0x3c)[0x43e5cc]
./test[0x8048512]
/lib/libc.so.6(__libc_start_main+0xe0)[0x3e8f70]
./test[0x80483e1]
======= Memory map: ========
00235000-0023f000 r-xp 00000000 fd:00 360450 /lib/libgcc_s-4.1.2-20070626.so.1
0023f000-00240000 rwxp 00009000 fd:00 360450 /lib/libgcc_s-4.1.2-20070626.so.1
003d3000-00521000 r-xp 00000000 fd:00 360473 /lib/libc-2.6.so
00521000-00522000 r-xp 0014e000 fd:00 360473 /lib/libc-2.6.so
00522000-00524000 rwxp 0014f000 fd:00 360473 /lib/libc-2.6.so
00524000-00527000 rwxp 00524000 00:00 0
00616000-00631000 r-xp 00000000 fd:00 360466 /lib/ld-2.6.so
00631000-00632000 r-xp 0001a000 fd:00 360466 /lib/ld-2.6.so
00632000-00633000 rwxp 0001b000 fd:00 360466 /lib/ld-2.6.so
006c0000-006c1000 r-xp 006c0000 00:00 0 [vdso]
08048000-08049000 r-xp 00000000 fd:00 3473718 /home/gucchi/test/test
08049000-0804a000 rw-p 00000000 fd:00 3473718 /home/gucchi/test/test
09b61000-09b82000 rw-p 09b61000 00:00 0
b7e00000-b7e21000 rw-p b7e00000 00:00 0
b7e21000-b7f00000 ---p b7e21000 00:00 0
b7fd6000-b7fd8000 rw-p b7fd6000 00:00 0
bfb07000-bfb1c000 rw-p bfb07000 00:00 0 [stack]
アボートしました

というエラーがでます。
試しに他の環境でコンパイルしたら実行できちゃいました。
glibcに問題があったりするんでしょうか?
ご教授ください。

A 回答 (4件)

次のプログラムの結果はどうなりますか?


#include <stdio.h>
int main()
{
static const char msg[] = "これは16文字です";
printf("%zu\n", sizeof msg);
return 0;
}

この回答への補足

このプログラムを実行したら
24
と表示されました。
ということはmalloc(24)しなければならないということですか?

補足日時:2007/11/13 16:03
    • good
    • 0

日本語で使う文字だと,


・shift_jis では 2バイト/文字 (今さら使わないと思うけど, いわゆる半角カナは 1バイト/文字)
・utf-8 では 3~4バイト/文字 (2バイトの範囲には, 「普通使いそうな文字」はなかったと思う: 表を見ないと正確なことはわかりませんが)
でしょう. 多分.
ところで, もとの malloc で「十分」確保した場合には動きますか? ひょっとしたら表示のところが変になるかもしれませんよ.
    • good
    • 0
この回答へのお礼

遅くなってすみません。
malloccで十分に確保した場合(今回は100)も正常に動作しました。
表示もふつうに「これは16文字です.」と出ました。
いろいろとありがとうございます。

お礼日時:2007/11/16 17:24

#1 です.


あ~やっぱりね~. そんなところだと思ったんだ~.
その環境では "これは16文字です" という文字列は (最後の '\0' を含めて) 24バイトだから, 少なくとも 24バイト確保しておかないとうまく動かない (かもしれない) です. 文字コードは UTF-8 かなぁ?
ちなみに「そんな風に思った」根拠は, glibc のメッセージにあります. これ, (とてつもなく) 意訳すると「realloc しようとしたけど, メモリを管理するための領域がぶっ壊れていて無理だから死にます」って意味です. となれば, 怪しいのは「realloc するための管理領域をいじることのできる場所」で, それは malloc したあとの strcpy 以外にありえません. しかも, これが怪しいと仮定すると「実は文字列の長さが違っている」ことくらいしか考えられないので, #1 に挙げたテストプログラムにいきつきます.

この回答への補足

なるほど。
ありがとうございます。
そうなると、文字コードによってサイズが違うということですか?
shift-jisは2byte/1文字
utf-8は3byte/1文字
ということでしょうか?

補足日時:2007/11/14 03:17
    • good
    • 0

> printf(p);



printf()の第1引数が書式文字列以外である点に、
問題が潜んでいるのではないでしょうか。

上記の文を、
printf("%s\n", p);
のように変えてみたとき、実行結果はどうなるでしょうか。

この回答への補足

やってみたところ結果はまったく同じでした。

補足日時:2007/11/13 16:07
    • good
    • 0

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!