On 19 Feb 2003 at 11:36, Martin Pool wrote:
On 18 Feb 2003, Ludolf Holzheid [EMAIL PROTECTED] wrote:
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
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
Look at other parts in the code, a nice idea is to compare character by
character until the string is an ASCII one, as soon as we detect a non
ascii character we revert to the standard method and re-compare the
strings, Tridge has gained very good optimizations with this twchnique.
Simo.
On Tue,
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
On Tue, Feb 18, 2003 at 10:49:28PM +0100, Ludolf Holzheid wrote:
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.
StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only
compares the first PSTRING_LEN (1024) bytes of the strings.
I suppose comparing strings longer than that is probably a bit
unlikely, but it still seems kind of dangerous.
Would it be OK to change it to use dynamic
On Tue, 2003-02-18 at 11:01, Martin Pool wrote:
StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only
compares the first PSTRING_LEN (1024) bytes of the strings.
I suppose comparing strings longer than that is probably a bit
unlikely, but it still seems kind of
On 18 Feb 2003, Andrew Bartlett [EMAIL PROTECTED] wrote:
Possibly only for long strings? But then that is probably
micro-optimization.
If we really cared about optimizing this function, then we would
compare character-by-character rather than converting both strings to
uppercase first.
On Tue, 18 Feb 2003 11:35:32 +1100
Martin Pool [EMAIL PROTECTED] wrote:
On 18 Feb 2003, Andrew Bartlett [EMAIL PROTECTED] wrote:
Possibly only for long strings? But then that is probably
micro-optimization.
If we really cared about optimizing this function, then we would
compare
On Tue, Feb 18, 2003 at 11:01:53AM +1100, Martin Pool wrote:
StrCaseCmp (and strequal) in HEAD has the interesting side-effect that it only
compares the first PSTRING_LEN (1024) bytes of the strings.
I suppose comparing strings longer than that is probably a bit
unlikely, but it still seems
On 18 Feb 2003, [EMAIL PROTECTED] wrote:
What exactly do you want to do here ? I'm not clear what
you mean?
The thing I noticed is that StrCaseCmp (and indeed many charcnv
function) truncate strings to 1024 characters.
I got here following a Valgrind assertion which may or may not be
On Tue, Feb 18, 2003 at 03:23:40PM +1100, Martin Pool wrote:
On 18 Feb 2003, [EMAIL PROTECTED] wrote:
What exactly do you want to do here ? I'm not clear what
you mean?
The thing I noticed is that StrCaseCmp (and indeed many charcnv
function) truncate strings to 1024 characters.
I
12 matches
Mail list logo
