a shorter strchr

[Servé Lau]

Sometimes I code like this:

char *p = strchr(buf,'\n');
if (p)
*p = 0;

But I've also seen the shorter expression:

buf[strcspn(buf, '\n')] = 0;

Are their advantages to the second one except shorter code?

[Spacen Jasset]

"Servé Lau" <se***@detongiser.com> wrote in message
news:10*************@corp.supernews.com...

Sometimes I code like this:

char *p = strchr(buf,'\n');
if (p)
*p = 0;

But I've also seen the shorter expression:

buf[strcspn(buf, '\n')] = 0;

Are their advantages to the second one except shorter code?

I can't think of any. strcspn might be a bit slower than strchr, because it
is designed to look for a set of characters in a string.

What you have in the second case is slightly wrong, a typo perhaps. strcspn
takes a constant character pointer as it's second argument.
So it should be:
buf[ strcspn(buf, "\n") ] = 0;

[David Rubin]

Spacen Jasset wrote:

char *p = strchr(buf,'\n');
if (p)
*p = 0;
[or...]buf[strcspn(buf, '\n')] = 0; Are their advantages to the second one except shorter code?

I can't think of any. strcspn might be a bit slower than strchr, because it
is designed to look for a set of characters in a string.

Indeed. Also, "shorter" is relative. What appears shorter to you may be
many times longer to the CPU. Just try to strike a reasonable balance
between terseness and readability. Another idiom is

if((p=strchr(buf, '\n')))
*p = 0;

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

[nrk]

Serv�Lau wrote:

Sometimes I code like this:

char *p = strchr(buf,'\n');
if (p)
*p = 0;

But I've also seen the shorter expression:

buf[strcspn(buf, '\n')] = 0;

Are their advantages to the second one except shorter code?

The call to strcspn is incorrect. It should be:
buf[strcspn(buf, "\n")] = 0;

One (likely inconsequential) difference is that the second call will always
write a null to the string. There might be some performance trade-offs as
strcspn will be scanning the string for a *set* of characters that it
shouldn't find, while strchr searches for exactly one character which is
considerably more straightforward. Also, as a style issue, I would
probably not go for embedding a function call like that into the index of
an array in the assignment statement.

-nrk.

--
Remove devnull for email

[pete]

Spacen Jasset wrote:

"Servé Lau" <se***@detongiser.com> wrote in message
news:10*************@corp.supernews.com...

Sometimes I code like this:

char *p = strchr(buf,'\n');
if (p)
*p = 0;

But I've also seen the shorter expression:

buf[strcspn(buf, '\n')] = 0;

Are their advantages to the second one except shorter code?
I can't think of any.
strcspn might be a bit slower than strchr, because it
is designed to look for a set of characters in a string.

Conceptually, strcspn can be described as looping calls to strchr.

size_t strcspn(const char *s1, const char *s2)
{
const char *const p1 = s1;

while (strchr(s2, *s1) == NULL) {
++s1;
}
return s1 - p1;
}
What you have in the second case is slightly wrong,
a typo perhaps. strcspn
takes a constant character pointer as it's second argument.
So it should be:
buf[ strcspn(buf, "\n") ] = 0;

A briefer, more computationally intensive way of writing it would be:

strtok(buf, "\n");

--
pete

[David Rubin]

pete wrote:

char *p = strchr(buf,'\n');
if (p)
*p = 0;
[or]buf[strcspn(buf, '\n')] = 0;

[snip] A briefer, more computationally intensive way of writing it would be:

strtok(buf, "\n");

However, this is not readable at all since the intent is unclear and the
effect is merely a byproduct of the function's semantics.

/david

--
Andre, a simple peasant, had only one thing on his mind as he crept
along the East wall: 'Andre, creep... Andre, creep... Andre, creep.'
-- unknown

[Dan Pop]

In <c0*******@netnews.proxy.lucent.com> David Rubin <no****@nowhere.net> writes:

pete wrote:

A briefer, more computationally intensive way of writing it would be:

strtok(buf, "\n");

However, this is not readable at all since the intent is unclear and the
effect is merely a byproduct of the function's semantics.

I disagree: the return value being ignored, it is (or should be) OBVIOUS
that this function was called *exclusively* for its side effect(s).

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Spacen Jasset]

"pete" <pf*****@mindspring.com> wrote in message
news:40**********@mindspring.com...

....

A briefer, more computationally intensive way of writing it would be:

strtok(buf, "\n");

That does not work how the other methods do though. In particular, it would
not remove '\n' at the begining of the string. From the NetBSD man pages:

" The strtok() function returns a pointer to the beginning of each subse-
quent token in the string, after replacing the separator character
itself
with a NUL character. Separator characters at the beginning of the
string or at the continuation point are skipped so that zero length to-
kens are not returned. When no more tokens remain, a null pointer is
re-
turned."

[pete]

Spacen Jasset wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:40**********@mindspring.com...

...

A briefer, more computationally intensive way of writing it would be:

strtok(buf, "\n");

That does not work how the other methods do though.
In particular, it would
not remove '\n' at the begining of the string.

Good catch. Thank you.

--
pete