In the embedded/real time world, malloc() and friends are strongly deprecated as you can't predict how long they will take. They have to go through a linked list of unknown length and may even start a garbage collection.
If StrCaseCmp() is really that sensitive w.r.t. processor cycles, you better keep the malloc()ed buffers between the calls and increase their size (by calling free() and malloc(), not realloc()) if the strings to be compared do not fit. (well, if the string lengths are really not limited, this may turn out as a memory leak...) Ludolf On 18 Feb 2003 at 8:04, [EMAIL PROTECTED] wrote: > On Tue, Feb 18, 2003 at 06:23:41PM +1100, Martin Pool wrote: > > > One little malloc() could hardly make it any worse, although I will do > > a test tomorrow to check. > > "One little malloc()" - I'll remind you of that quote later :-). > > But please do the test, that's the only way we can really > be sure if it's a speedup or not. > > Jeremy. > --------------------------------------------------------------- Ludolf Holzheid Tel: +49 621 339960 Bihl+Wiedemann GmbH Fax: +49 621 3392239 Flosswoerthstrasse 41 e-mail: [EMAIL PROTECTED] D-68199 Mannheim, Germany ---------------------------------------------------------------