Tryiing just to read/understand this code

[smnoff]

Below is a section from string.c at this
linkhttp://cvs.opensolaris.org/source/xref/on/usr/src/common/util/string.cthat
I am trying to fully understand.I don't fully understand LINE 514; not to
mention that entire inner while loop and what it'strying to accomplish. I
figured that if I can at least understand each line of this strstr methodand
why it's written the ways it written, as well as in regards to perfomance or
code simplicity, it will help me learn c.Thanks. 497 char *
498 strstr(const char *as1, const char *as2)
499 {
500 const char *s1, *s2;
501 const char *tptr;
502 char c;
503
504 s1 = as1;
505 s2 = as2;
506
507 if (s2 == NULL || *s2 == '\0')
508 return ((char *)s1);
509 c = *s2;
510
511 while (*s1)
512 if (*s1++ == c) {
513 tptr = s1;
514 while ((c = *++s2) == *s1++ && c)
515 ;
516 if (c == 0)
517 return ((char *)tptr - 1);
518 s1 = tptr;
519 s2 = as2;
520 c = *s2;
521 }
522
523 return (NULL);
524 }

[websnarf]

smnoff wrote:

So I got to ask, why does code get written like this to begin with?
Especially since this is library code? Job Security? Just because they can?
Neat trick?

I'll go with "because they can". (There are certainly no "tricks" in
that code worthy of note.) When you have multiple side effects on one
line (i.e., the while ((c = *++s2) == *s1++ && c);) you should either
split them up or comment it very profusely. In this case, they are not
even being the most efficient:

for (s2++; (c = *s2) == *s1; s2++,s1++) {
if (!c) return (char *) tptr - 1;
}

This way the last test on c is always only carried out only once.

Jacob Navia posted the gcc source code for strstr here a little while
ago. Now *that* code is hairy. But at least they justify it by being
fairly fast. Now of course, why none of this code is commented is
beyond me. It probably should be.

If you want to see a fast implementation of something very similar to
strstr that is well commented you can download the Better String
Library here:

http://bstring.sf.net/

And search for the binstr() function.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Keith Thompson]

we******@gmail.com writes:
[...]

Jacob Navia posted the gcc source code for strstr here a little while
ago. Now *that* code is hairy. But at least they justify it by being
fairly fast. Now of course, why none of this code is commented is
beyond me. It probably should be.

<OT>
As far as I know, there is no gcc source code for strstr. He may have
posted the glibc source code for strstr.

gcc is a compiler, not a full implementation. It typically uses
whatever C runtime library is provided by the underlying operating
system.
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[ena8t8si]

Chris Dollin wrote:

en******@yahoo.com wrote:

Chris Dollin wrote:

jmcgill wrote:

ozbear wrote:

Ugh!


I didn't write it. I only formatted it.
Don't tell me you preferred the original, with no indents,
and overly economical braces.

One can think that both are unnecessarily ugly.

[And I've heard no convincing argument for using brackets on
control structure arguments when they are only one-statement
blocks.]

Out of curiousity, what arguments have you heard?

That not using brackets means that when additional statements
are added to the controlled statement, the adder won't put
in the brackets and the code will be broken.

One should be consistent.

The local style guide says so.

Thank you, I appreciate the reply.

Do your comments mean that you've never experienced
someone adding a line of code and forgetting to add
the braces?

[Chris Dollin]

en******@yahoo.com wrote:

>
Chris Dollin wrote:

>en******@yahoo.com wrote:

>
Out of curiousity, what arguments have you heard?

That not using brackets means that when additional statements
are added to the controlled statement, the adder won't put
in the brackets and the code will be broken.

One should be consistent.

The local style guide says so.

Thank you, I appreciate the reply.

Do your comments mean that you've never experienced
someone adding a line of code and forgetting to add
the braces?

To the best of my knowledge, that's right. But my C
experience is limited and mostly on single-person
projects. (Were I working on a new C project, I'd
expect any such theoretical [1] problem to be caught
by the unit tests anyway.)

[1] From my POV.

--
Chris "seeker" Dollin
"Who do you serve, and who do you trust?" /Crusade/

[CBFalconer]

en******@yahoo.com wrote:

Chris Dollin wrote:

.... snip ...

>>
That not using brackets means that when additional statements
are added to the controlled statement, the adder won't put
in the brackets and the code will be broken.

One should be consistent.

The local style guide says so.

Thank you, I appreciate the reply.

Do your comments mean that you've never experienced someone adding
a line of code and forgetting to add the braces?

My personal attitude is that braces should be used whenever
multiple source lines are used, but can be avoided for a single
source line. I.E:

if (whatever) dosomething(foolish);
else {
foolish = 0;
dosomethingelse(foolish);
}

If something is added to the single statement portion it is highly
obvious that a set of braces are needed.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>