Question on strncmp / strnicmp use

[CBFalconer]

I checked through that code and spotted the missing *, but not
the logic error.

Twinkletroll is actually correct. There is no logic error, that is
a consequence of the type (omitting the * in !*s2).

 

[CBFalconer]

....

Why is everyone keen on offering untested bits of code when all
the OP wants is a better way of using strncmp()?

Because the 'untested code' (if you insert the missing *) is much
more efficient than all those library calls. It also doesn't
depend on the lack of system library errors.

People should think first about the problem, and then if some of
the standard library calls fit it well.

 

[CBFalconer]

That can't be serious question after I wrote taking about the
pros and cons of using two strlens vs. a hand-rolled version.

I am not sure there is a way to write it using only library
functions so that you never look further than the shorter of
the two strings. I am in rush at the moment, but nothing
occurs to me.

Take a look at my qmatch routine (if you insert the missing * in
the exit operation). It never looks past the shorter string. It
never looks past the first difference. It never calls strlen. It
never calls anything. It's earlier in the thread.

 

[Barry Schwarz]

I neglected to add, thinking it was obvious and I was wrong as it isn't
so obvious, "same length and same strings". The comparison loop would go past
the nul.

But it is so obvious that I'm embarrassed to have missed it.

 

[Ben Bacarisse]

Ben Bacarisse wrote:

Take a look at my qmatch routine (if you insert the missing * in
the exit operation). It never looks past the shorter string. It
never looks past the first difference. It never calls strlen. It
never calls anything. It's earlier in the thread.

I know. So is my non-library solution. Why should I look (again) at
yours? You say it uses no library calls so what does it have to do
with my post? I was wondering if there was a solution using only
standard library calls that avoids looking at any more than
min(strlen(s1), strlen(s2)) characters from either string (as all the
hand-rolled versions manage do).

 

[CBFalconer]

I know. So is my non-library solution. Why should I look (again)
at yours? You say it uses no library calls so what does it have
to do with my post? I was wondering if there was a solution using
only standard library calls that avoids looking at any more than
min(strlen(s1), strlen(s2)) characters from either string (as all
the hand-rolled versions manage do).

Sorry. Never noticed your non-lib solution. I am only objecting
to using library calls in the first place for such simple things.
That involves more overhead, more code linking, etc.

qmatch can also be made more useful. It can return 0 for equal, 1
for parameter 1 contained in parameter 2, and 2 for the converse.

 

[Bartc]

Ben Bacarisse wrote:

Sorry. Never noticed your non-lib solution. I am only objecting
to using library calls in the first place for such simple things.
That involves more overhead, more code linking, etc.

I'm trying to get my head around those statements.

So, you're saying it's best to ignore the C library, and write your own code
instead, because it might make your project take a bit longer to link?

The advice in this group is usually to avoid early optimisation, and the OP
in fact said nothing about efficiency, yet the advice in this thread seems
to be to rewrite the library functions (even though they may be highly
tweaked for the platform).

(There's nothing wrong with writing a string library to augment/improve the
built-in one, but it seems overkill for this problem.)

 

[Antoninus Twink]

[nonsense snipped]

So, you're saying it's best to ignore the C library, and write your own code
instead, because it might make your project take a bit longer to link?

Absurd, isn't it?

The advice in this group is usually to avoid early optimisation, and
the OP in fact said nothing about efficiency, yet the advice in this
thread seems to be to rewrite the library functions (even though they
may be highly tweaked for the platform).

Absurd, isn't it?

(There's nothing wrong with writing a string library to augment/improve the
built-in one, but it seems overkill for this problem.)

Agreed.

 

[CBFalconer]

I'm trying to get my head around those statements.

So, you're saying it's best to ignore the C library, and write your
own code instead, because it might make your project take a bit
longer to link?

No. However, it is advisable to have an idea of how much code you
have to write, and how much code you would have to call. Without a
reasonable feel for such things you can't make intelligent
decisions.

 

[Ben Bacarisse]

Sorry. Never noticed your non-lib solution. I am only objecting
to using library calls in the first place for such simple things.
That involves more overhead, more code linking, etc.

I asked mainly as an intellectual challenge but it is probably not
possible. In general I *prefer* code to use library calls, but in
this case there is an algorithmic cost. The cost of overheads and
linking is not significant to me.

 

[Guest]

testing it might be a better idea.

But its not just me of course. Richard Stallman wrote uses gdb for a
reason.

Here:

Why Not Use Printf?
===================http://dirac.org/linux/gdb/01-Introduction.php#whynotuse<tt>print...

I know I go on about it, but I have rarely, if ever, seen anyone debug a
system with printf quicker than learning how to use a proper debugger
properly. It is simply ludicrous NOT to use one in this day and age on
large code bases where HW breakpoints and complicated watch points make
it trivial to catch complex state which trigger bugs.

When you catch a bug you can move up and down the stack to see the
variables which contributed to that bug. No wads of printf logs to wade
though. You can often rewind the code. You can change locals to trigger
the bug etc etc etc. Only people who do NOT know what a debugger is or
know how to use one properly argue against these benefits.

But we've discussed this a million times before. If someone wants to
blinker themselves and NOT learn how to use something as potentially
powerful as GDB then that's their decision. A silly one.

As most people are aware Richard has a bit of a bee in his bonnet
about
this one (to the point of misrepresenting people).

From the link above:
"However, this isn't to say that printf() has no use in debugging.
Sometimes it's the best way to go." Richard Stallman

assert(), activity logging, error reporting, good unit tests
and a debugger are all ways to help in writing correct
prograsm and to debug incorrect ones.


--
Nick Keighley

printf() is your debugging friend! (We've all needed to
set breakpoints or pore over coredumps back in the day,
but judicious use of "if (TEST) printf()" is the
straightforward way to address most testing and debugging.)
(James Dow Allen clc)

 

[Phil Carmody]

I'm trying to get my head around those statements.

So, you're saying it's best to ignore the C library, and write your
own code instead, because it might make your project take a bit longer
to link?

The advice in this group is usually to avoid early optimisation, and

min(n,m) << m+n+min(m,n)

That's not early optimisation, that's algorithm choice.

the OP in fact said nothing about efficiency, yet the advice in this
thread seems to be to rewrite the library functions

Nothing of the sort has been suggested. Writing a function which
does O(min(n,m)) work rather than using 3 invocation of library
functions which are all Omega(min(n,m)) is *not* rewriting the
library functions. It's writing something that does what you want,
and nothing more, in the context of having a selection of library
functions which don't do what you want.

(There's nothing wrong with writing a string library to
augment/improve the built-in one, but it seems overkill for this
problem.)

Hardly. A 3-line single loop is no more overkill than 3 separate
calls to library functions.

Phil

 

[Bartc]

min(n,m) << m+n+min(m,n)

That's not early optimisation, that's algorithm choice.

If I understood what that equation meant, I could make a comment.

Nothing of the sort has been suggested. Writing a function which
does O(min(n,m)) work rather than using 3 invocation of library
functions which are all Omega(min(n,m)) is *not* rewriting the
library functions. It's writing something that does what you want,
and nothing more, in the context of having a selection of library
functions which don't do what you want.

You admit this simple task can be accomplished with 3 calls to simple
building block functions in the library. Functions which are tried and
tested.

If the task was to compare the shorter string with the /end/ of the longer
string instead, a simple rearrangement of the same 3 calls would suffice.
The dedicated code on the other hand would need rewriting. All for a
comparison which for all we know is only done once in the program.

 

[Keith Thompson]

You admit this simple task can be accomplished with 3 calls to simple
building block functions in the library. Functions which are tried and
tested.

If the task was to compare the shorter string with the /end/ of the longer
string instead, a simple rearrangement of the same 3 calls would suffice.
The dedicated code on the other hand would need rewriting. All for a
comparison which for all we know is only done once in the program.

(The original problem was to determine, for two arbitrary strings,
whether either one is an initial substring of the other.)

Maybe it's done only once in the program, or maybe it's done a billion
times with multi-kilobyte strings.

There is no solution that *just* uses library functions; you have to
write some code to call them. A solution that calls strlen() on both
strings must scan both strings to the end; a hand-written solution can
ignore the excess characters of the longer string, which *might* be a
significant performance improvement.

If you're sure performance isn't going to be an issue (the strings
never differ much in length, or you know strlen() is optimized better
than any portable hand-written code you could write, or the function
is called rarely enough that it's not going to be a performance
bottleneck), then go ahead and write the simpler code that calls
strlen() on both strings. Otherwise, the hand-written version can be
a perfectly reasonable optimization.

Library functions are tried and tested, but they aren't a magic bullet
-- and any code you write had better be tried and tested itself
(though not as extensively as the standard library functions, or even
a particular implementation of them). An extreme example: on some
programming Q&A forum, somebody asked how to find the minimum element
of a array without using a loop. The proposed solution was to sort
the array and take the first element.

 

[Phil Carmody]

If I understood what that equation meant, I could make a comment.

There was no equation. There was a 'significantly less than' comparison.

You admit this simple task can be accomplished with 3 calls to simple
building block functions in the library. Functions which are tried and
tested.

for(; is tried and tested. * and == are tried and tested. And
finally ++ is tried and tested. That's basically all this routine
needs, and the logic is so simple that anyone who can't write it
correctly should be given a good slap.

If the task was to compare the shorter string with the /end/ of the longer
string instead, a simple rearrangement of the same 3 calls would suffice.
The dedicated code on the other hand would need rewriting. All for a
comparison which for all we know is only done once in the program.

If the task was to do something different, then I'd write a function
that did something different. But given that the question was not
about something different, there's little point in addressing it.

Phil

 

[Bartc]

for(; is tried and tested. * and == are tried and tested. And
finally ++ is tried and tested. That's basically all this routine
needs, and the logic is so simple that anyone who can't write it
correctly should be given a good slap.

Fine. So we go along with CBF and just ignore any of C's standard functions
that can be rewritten in half-a-dozen or fewer lines of code, in the
interests of efficiency, whether that efficiency is needed or not.

If the task was to do something different, then I'd write a function
that did something different. But given that the question was not
about something different, there's little point in addressing it.

My point is, we don't know the full picture. But OK, write dedicated code
for the original simple task. And more dedicated code for the next slightly
different task. And the next..

 

[CBFalconer]

.... snip ...

Fine. So we go along with CBF and just ignore any of C's standard
functions that can be rewritten in half-a-dozen or fewer lines of
code, in the interests of efficiency, whether that efficiency is
needed or not.

If you actually read the appropriate messages you would see that
this canard is totally untrue.