Tryiing just to read/understand this code

[Default User]

I am a little confused on the WHILE loop at line 511 shown below(or

Please don't top-post. Your replies belong following or interspersed
with properly trimmed quotes.




Brian

 

[pete]

jmcgill wrote:

In my shop, you'd format it like this, or maybe you'd be happier
elsewhere

while ((c = *++s2) == *s1++ && c);

ITYM

while ((c = *++s2) == *s1++ && c) {
;
}

This is my version of strstr:

#include <stddef.h>

char *str_str(const char *s1, const char *s2);
size_t str_len(const char *s);
char *str_chr(const char *s, int c);
int str_ncmp(const char *s1, const char *s2, size_t n);

char *str_str(const char *s1, const char *s2)
{
const int c = *s2++;

if (c != '\0') {
const size_t n = str_len(s2);

s1 = str_chr(s1, c);
while (s1 != NULL && str_ncmp(s1 + 1, s2, n) != 0) {
s1 = str_chr(s1 + 1, c);
}
}
return (char *)s1;
}

size_t str_len(const char *s)
{
size_t n;

for (n = 0; *s != '\0'; ++s) {
++n;
}
return n;
}

char *str_chr(const char *s, int c)
{
while (*s != (char)c) {
if (*s == '\0') {
return NULL;
}
++s;
}
return (char *)s;
}

int str_ncmp(const char *s1, const char *s2, size_t n)
{
const unsigned char *p1 = (const unsigned char *)s1;
const unsigned char *p2 = (const unsigned char *)s2;

while (n-- != 0) {
if (*p1 != *p2) {
return *p2 > *p1 ? -1 : 1;
}
if (*p1 == '\0') {
return 0;
}
++p1;
++p2;
}
return 0;
}

 

[jmcgill]

ITYM

while ((c = *++s2) == *s1++ && c) {
;
}

Yeah, of course. It actually made me cringe earlier. I *know* what's
valid, but I don't *like* it.

This is my version of strstr:

Much easier on the eyes.

 

[jmcgill]

I think you missed something here.

I think all I did was run the code through indent and maybe added a pair
of brackets.

Your questions all need to be directed to someone who codes for the open
version of the string library for Solaris, which is where I was led to
believe this code originated.

 

[ozbear]

Yeah. And I totally refuse to buy any argument I've ever heard
against using brackets on control structures, even when they are only
one-statement blocks.

In my shop, you'd format it like this, or maybe you'd be happier
elsewhere

strstr(const char *as1, const char *as2)
{
const char *s1,
*s2;
const char *tptr;
char c;

s1 = as1;
s2 = as2;

if (s2 == NULL || *s2 == '\0') {
return ((char *) s1);
}
c = *s2;

while (*s1) {
if (*s1++ == c) {
tptr = s1;
while ((c = *++s2) == *s1++ && c);
if (c == 0) {
return ((char *) tptr - 1);
}
s1 = tptr;
s2 = as2;
c = *s2;
}
}
return (NULL);
}

Ugh!

Oz

 

[jmcgill]

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.

 

[Chris Dollin]

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.]

 

[Flash Gordon]

I think all I did was run the code through indent and maybe added a pair
of brackets.

Your questions all need to be directed to someone who codes for the open
version of the string library for Solaris, which is where I was led to
believe this code originated.

Possibly, or possibly you missed the return type on a cut and paste.
However, it was definitely missing.

 

[ena8t8si]

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?

 

[Chris Dollin]

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.

 

[websnarf]

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.

 

[Keith Thompson]

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>

 

[ena8t8si]

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?

 

[CBFalconer]

Chris Dollin wrote:
.... snip ...

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.

 

[Chris Dollin]

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.