How to test whether strstr() returns a null pointer or not?

[John Smith]

How to test whether strstr() returns a null pointer or not? Do I
use something like the following?

if(NULL != strstr(str1,str2))

That does not seem to work.

 

[SM Ryan]

# How to test whether strstr() returns a null pointer or not? Do I
# use something like the following?
#
# if(NULL != strstr(str1,str2))

if (strstr(str1,str2))

always works for me.

#
# That does not seem to work.
#
#

 

[Barry Schwarz]

How to test whether strstr() returns a null pointer or not? Do I
use something like the following?

if(NULL != strstr(str1,str2))

That does not seem to work.

Does not work how? Tell us what you expect and what actually
happens. Provide some compilable code that demonstrates this
behavior.


<<Remove the del for email>>

 

[Emmanuel Delahaye]

John Smith wrote on 04/06/05 :

How to test whether strstr() returns a null pointer or not? Do I
use something like the following?

if(NULL != strstr(str1,str2))

That does not seem to work.

Give a complete example. I suspect that the strings pointed by str1 and
str2 are not the ones you are expecting (say, a extra trailing '\n' for
example...).

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"There are 10 types of people in the world today;
those that understand binary, and those that dont."

 

[Lawrence Kirby]

# How to test whether strstr() returns a null pointer or not? Do I
# use something like the following?
#
# if(NULL != strstr(str1,str2))

Yes, that's one way of doing it

if (strstr(str1,str2))

The 2 forms are equivalent so if one doesn't work the other won't either.

Lawrence

 

[Malcolm]

The 2 forms are equivalent so if one doesn't work the other won't either.

He might have manged to redefine NULL.

..backwards expressions read to Hard

 

[John Smith]

# How to test whether strstr() returns a null pointer or not? Do I
# use something like the following?
#
# if(NULL != strstr(str1,str2))

if (strstr(str1,str2))

always works for me.

Thanks. That works.

 

[John Smith]

Does not work how? Tell us what you expect and what actually
happens. Provide some compilable code that demonstrates this
behavior.

Not sure. But if(strstr(str1,str2)) works. So I'll just use that.

 

[Paul Mesken]

Thanks. That works.

That's really odd.

if (NULL != strstr(str1, str2))

should be equivalent to

if (strstr(str1, str2))

which should also be equivalent to

if (0 != strstr(str1, str2))

(the use of NULL instead of 0 is a stylistical thing)

What exactly didn't work in your program? I believe the Standard only
requires the macro NULL to be defined in <stddef.h>. Perhaps if you
include <stddef.h> in your program it will work.

 

[Paul Mesken]

I believe the Standard only
requires the macro NULL to be defined in <stddef.h>.

And <locale.h>, <stdlib.h>, <stdio.h>, <string.h>, <time.h>

Furrfu, that Standard could use a better index

Well, in that case NULL might have been redefined as someone else
suggested, since NULL is defined in <string.h> and you use strstr()
(which, I hope, implies that you also included <string.h>

 

[Barry Schwarz]

Not sure. But if(strstr(str1,str2)) works. So I'll just use that.

Then how do you know it didn't work? The two statements are
equivalent. Your change is cosmetic. What is the real problem? Did
you include string.h? Do you have your warning level set to max?


<<Remove the del for email>>

 

[John Smith]

Then how do you know it didn't work? The two statements are
equivalent. Your change is cosmetic. What is the real problem? Did
you include string.h? Do you have your warning level set to max?

A window popped up asking for permission to report the problem to
Microsoft. That's how I knew something was wrong. Anyway, since
the program is working now, I'll just leave the mistery behind and
forget about it.

 

[Keith Thompson]

Thanks. That works.

That's really odd. [...]
What exactly didn't work in your program? I believe the Standard only
requires the macro NULL to be defined in <stddef.h>. Perhaps if you
include <stddef.h> in your program it will work.

If the OP didn't #include one of the headers that defines NULL, he
should have gotten a compilation error. Since all he told us was that
"That does not seem to work", I'm assuming it compiled but didn't
behave the way he expected. (Note to everyone posting questions: you
need to tell us *how* it doesn't work.)

If NULL has been redefined somewhere, he needs to track it down and
fix it. Redefining NULL is a very bad idea.

 

[Keith Thompson]

A window popped up asking for permission to report the problem to
Microsoft. That's how I knew something was wrong. Anyway, since
the program is working now, I'll just leave the mistery behind and
forget about it.

It's very likely that the error was a symptom of a deeper problem
that's going to bite you again later on. The change you made should
not have made any difference. It's up to you whether you want to
spend time tracking it down, but I'd advise doing so.

 

[Malcolm]

It's very likely that the error was a symptom of a deeper problem
that's going to bite you again later on. The change you made should
not have made any difference. It's up to you whether you want to
spend time tracking it down, but I'd advise doing so.

The bug is in the compiler. That's why MS want a bug report.

The thing to do (easier said than done) is to run the code through another
compiler to see if everything is correct.
If you are stuck with a bad compiler, there's nothing much you can do,
except look at unusual constructs to see what is causing it to misbehave, or
what the OP is doing, which is to play with the code and hope the problem
goes away.

 

[Keith Thompson]

The bug is in the compiler. That's why MS want a bug report.

Is it? Does the "report the problem to Microsoft" message reliably
indicate a bug in Microsoft's compiler, or could it be triggered by a
bug in the program itself? (I have no idea what the answer to that
question is.)

The thing to do (easier said than done) is to run the code through another
compiler to see if everything is correct.
If you are stuck with a bad compiler, there's nothing much you can do,
except look at unusual constructs to see what is causing it to misbehave, or
what the OP is doing, which is to play with the code and hope the problem
goes away.

If it's the result of undefined behavior in the program, recompiling
with another compiler coud very well *seem* to correct the problem.

 

[Malcolm]

Is it? Does the "report the problem to Microsoft" message reliably
indicate a bug in Microsoft's compiler, or could it be triggered by a
bug in the program itself? (I have no idea what the answer to that
question is.)

A bit OT, but yes.
Microsoft aren't interested if a developer has introduced a bug into his
program, except that obviously the compiler produces a diagnostic if
possible.
However they are interested if their own compiler / ide / debugger isn't
working. The message indicates that their program has encountered an
internal error, i.e. is bugged. (If it wasn't bugged before it popped up the
message box, it is bugged after).
That bug could be triggered by attempting to compile a legal program, or it
could be triggered by an illegal program. Either way it is Microsoft's
fault.

If it's the result of undefined behavior in the program, recompiling
with another compiler coud very well *seem* to correct the problem.

What I should have asked if whether the message appears at compile time or
run time. If it appears when the program is run under the debugger it is
probably a bug in the debugger rather than the compiler itself. It could
indeed be because the debugger cannot cope with undefined behaviour.
You are right that compiling on another compiler may mask the error. Once
your tool stop working reliably it is hard to know what to do.

 

[SM Ryan]

# if (NULL != strstr(str1, str2))
#
# should be equivalent to
#
# if (strstr(str1, str2))

You're presuming what NULL and strstr are defined to be.

 

[CBFalconer]

"Keith Thompson" <[email protected]> wrote

talking about "if(NULL != strstr(str1,str2))" failing.

The bug is in the compiler. That's why MS want a bug report.

The thing to do (easier said than done) is to run the code through
another compiler to see if everything is correct. If you are stuck
with a bad compiler, there's nothing much you can do, except look
at unusual constructs to see what is causing it to misbehave, or
what the OP is doing, which is to play with the code and hope the
problem goes away.

Please don't snip attributions for material you quote.

Assuming the author hasn't done some thing exorbitantly stupid,
such as redefining NULL, it seems we have the usual Microsloth
quality. If they can't correctly parse such a simple statement,
there must be no regression suite of tests in existance.

 

[pete]

talking about "if(NULL != strstr(str1,str2))" failing.

Assuming the author hasn't done some thing exorbitantly stupid,

Has it been established yet that <string.h> was #included?