Mail Archives: djgpp-workers/1998/05/07/05:24:29
Nate Eldredge wrote:
> I have uploaded my far pointer string/mem function package for testing.
This first ``bug''-report was from looking at the sources alone. I've
nothing compiled yet. Other tests results will follow.
I'm not very explanative here below. Please ask if I am not clear about
something.
I post this to c AT m-d because if I might be wrong about something someone
may want to correct me.
-----
Move/Push to/from seg regs can be lword -> faster and shorter encoding
When pointer to result is NULL -> should yield undefined behaviour
(meaning: libc functions shouldn't test it).
Count parameter should always have have type size_t (function
_farmemcpy).
typedef for seg and ofs seems a good idea.
``FIXME string operations'' remarks: FYI they are not generally slow
when they are
repz/repnz-ed. Intel knows where they are used for (I hope ;-)
Determining the length of a string is relatively an expensive operation.
_farstrchr therefore is not implemented well, IMO. Consider a string of
260
spaces. Using strchr to search for every space consecutively creates a
O(n^2)
algo because the first time 261 bytes are visited, next time 260, ... ,
2,
1.
The same but in lesser extend applies to _farstrcmp .
This also allows for the following type of optimizations (quite
important
time opt.):
Orig:
len = strlen (s)+1;
d = malloc (len);
strcpy (d, s);
Better:
len = strlen (s)+1;
d = malloc (len);
memcpy (d, s, len);
f.i. _farstrdup (and strdup) could be optimized using this technique
_farstrcat contains a bug.
_farstrcspn seem to contain a loop that may never end. At least that is
how I would think when I were a compiler.
_farstrrchr may not work with an ofs = 0.
I've a couple more remarks but I'll need to verify these before shouting
them out :-)
Cheers.
--
\ Vik /-_-_-_-_-_-_/
\___/ Heyndrickx /
\ /-_-_-_-_-_-_/ Knight in the Order of the Unsigned Types
- Raw text -