[H8-ML(4895)] Re: mallocについて。
From: FUJIHARA Keiichi <keiichi@xxxxxxxxxxxxx>
Date: 2004年07月11日(日)07時23分23秒
藤原と申します。

This message is reply to K.Mekata - san
(Subject was : [H8-ML(4893)] mallocについて。)

Message-ID: <000301c46669$bbf2d770$0301a8c0@slime>
in Sat, 10 Jul 2004 19:36:12 +0900 ...

> C:\PIC\h8\3052>..\l38h -subcommand=g.sub
> H8/300H LINKAGE EDITOR (Evaluation software) Ver.1.0
> 
> : OUTPUT g
> : PRINT g
> : INPUT resetv,LcdLib,g
> : LIB c38hab
> : START P,C,D(200),B(0FEF10)
> : EXIT
> ** 105 UNDEFINED EXTERNAL SYMBOL(malloc._sbrk)
> 
> とエラーがでます。

 えっと、憶測で書いていますので、はずしていたらご勘弁を。

 まず、
> ** 105 UNDEFINED EXTERNAL SYMBOL(malloc._sbrk)
 というエラーですが、これは、malloc がみつからないというのではなくて、
malloc.c が参照している、 _sbrk が見つからないという意味ではないかなと
思うわけです。
 手元にある、ルネサスの純正の処理系は、そういう意味でメッセージを出し
ます。

 そして、malloc のようなシステムに依存するライブラリは組み込みの場合、
ベンダーが準備することは不可能なわけです。ユーザーがどのようなメモリ
管理をするのか、わからないわけですから。
 このため、malloc の、骨格だけを準備して、さらに下位のルーチンは、
ユーザーが準備するような仕掛けにするわけですね。
 _sbrk がそういう、ユーザーが準備する関数なのだと思われます。

 あと、一般論ですが、malloc でメモリを確保する場合、単に、配列の宣言
に置き換えできないか(必要なメモリの量が決定できて、しかもそんなに多く
ない場合など)検討するのも良いようです。

 最後に、メーリングリストで新しい話題を起こす場合は、できれば、他の
メールへの返信ではなくて、新規のメールとして書いて頂けたらと思います。
 こちらで見ると、目片さんのメールは、H8-ML(4892)への返信になってい
るので、「なぜ、3068 のバスの話を malloc で解決?」と、一瞬悩むこと
になりますから。


-- 
_/ -- Last   811 hours until ATHENS 2004 Olympic Games -----------------
_/ FUJIHARA Keiichi
_/ E-Mail : keiichi@xxxxxxxxxxxxx <or> nagi@xxxxxxxxxxxxxxx
_/ URL    : http://www.keiichi.fujihara.name/
----------------------------------------------+----- Luna Phase 23.68 --
PGP FingerPrint = 7CC3 4F95 8CC7 87D3 7178  C348 CD65 7F08 D68F 69F6


スレッド概略
[4878(R)](起点)
 └[4893(U)]
   └[表示中]
     └[4896(1)]


投稿順に移動
[←前の記事へ(P)]
[→次の記事へ(N)]


リスト表示へ
[このスレッド(T)]
[本記事の前後(L)]