I suppose you could always use the -E flag to make sure strcasestr is actually there (as this is the warning I would expect if the prototype was missing). (Are you using -std or -ansi flags?)
Printable View
I suppose you could always use the -E flag to make sure strcasestr is actually there (as this is the warning I would expect if the prototype was missing). (Are you using -std or -ansi flags?)
Oh it's there. This works:
But obviously it's useless for illustrating my point. I have the same problem on my other computer, which is running a slightly older glibc/gcc (FC7-32 vs. FC10-64).Code:#include <string.h>
#include <stdio.h>
int main() {
char *ptr=strstr("this and that","and");
printf("%p %s\n",ptr,ptr);
ptr=strstr("this and that","and");
printf("%p %s\n",ptr,ptr);
return 0;
}
I'm not using the flags you mention, but I see no good reason for strcasestr to cause a segfault like that.
What do you think about what I was trying to say about the pointer addressess? How could two pointers with two values which appear different to me effectively point to the same place (like I said, the first find would be fine, but then the subsequent search would go awry because of the address returned from the first find -- meaning that pointer was no good for arithmetic)??
Maybe I got lost with what you were asking on the pointer question -- just because two pointers point to the same content doesn't mean they point to the same place.
I can't find anything weird about strcasestr; I get normal things, but I'm not using utf8 characters.
!!
huh...I had presumed that there is one copy of the buffer in memory, and that any pointer into that content must point into somewhere in that one copy.
So the incredibly simple example above, ptr=strcasestr(haystack,needle), does not segfault for you? There are not utf8 characters in that.Quote:
I can't find anything weird about strcasestr; I get normal things, but I'm not using utf8 characters.
I'd be curious to know, since I'm writing for other linux systems, and I would say FC7 and FC10 are very common. If it works on other systems, then our strcasestr is a dud.
I was using BSD/Mac OSX, and the "this and that" example worked fine.
I have no idea how (your version of) strcasestr is implemented -- I would expect it to point to the original piece of memory, but I don't think it's guaranteed. Maybe it is. Completely wild guess -- does strcasestr make a copy so that it can tolower/toupper the entire string and then use that memory? (I wouldn't think so, but hey.)
>> test.c:8: warning: assignment makes pointer from integer without a cast
That's bad news. Compile with '-Wimplicit'. I think tabstop was right-on about the prototype being missing. Some online man pages say _GNU_SOURCE is required.
gg
Well, I tried _GNU_SOURCE, -Wimplicit, even include <ctype.h> etc. No dice. Then I just added my own prototype at the top:
and it works. I'm kind of surprised; this has obviously been the case for several years.Code:char *strcasestr (const char *haystack, const char *needle);
Anyway, I won't be using strcasestr because, as tabstop confirms, it may return a pointer into a copy of (part of) haystack rather than into haystack itself.
>> it may return a pointer into a copy
I highly doubt it. All documentation suggests otherwise. Not to mention, there's no reason what-so-ever to make a copy.
gg
Yes, sorry, it meant it may as in "as far as I know, it's possible", not "as far as I know, it does".
We didn't expect -Wimplicit to stop segfaulting -- we expected -Wimplicit to give you a line that says "hey, I don't know what this strcasestr thing is" when you compiled.
So would I. But then, I would include a prototype if I was writing a function for the C library! So who knows?
Plus there is this, tho it may be just hearsay:
In fact, I had to put a control in so that if the return pointer was beyond the end of the search, the search would end (otherwise there was another seg fault for submitting this mystery pointer back to strcasestr). There's a toggle on the GUI to determine the case sensitivity, and lots of debugging to the console, so I could sit and just toggle the button on and off and hit return to do the exact same search on the exact same buffer, over and over. In both cases, the result in the GUI was the same -- str(case)str found the first term. But the pointer value in the debug output was, as I said, outside the buffer for strcasestr. Because I was just one substituting one function for another, there was nothing in my code which could account for the discrepancy.Quote:
Originally Posted by me
Perhaps intentionally leaving the prototype out is a coy way of indicating something...
An implicitly declared function is treated as returning int. That would be bad news on a 64bit system.
gg
What you actually wrote, being a smart, but perhaps a little inscrutable or cryptic person, who occasionally seems too lazy to completely explain him or herself to ignoramuses like me, is:
Using the -E flag just made me roll my eyes. If it knew what it was for, I suppose that might have meant the same thing as what you just wrote. Sorry! You know there is just too much information, and people like myself sometimes have to wear blinders so we don't get distracted by too many new things.Quote:
I suppose you could always use the -E flag to make sure strcasestr is actually there (as this is the warning I would expect if the prototype was missing).
Anyway, I was of the belief that if a function call actually works, then the function must be somewhere. That someone could include a function in a library somewhere without a prototype (as I guess is the case) wouldn't have occurred to me, especially since I don't think gcc would let me do that.
But thanks for your help, tabstop. I can live with "somewhat cryptic".
Could this explain the pointer wierdness? I would think the value would have to be the same anyway...although I notice on my 64 bit system, an int is actually twice as big as a pointer. Hmmm. Only with a very large buffer. Hmmm.
If I can find an older version of the code (way back when I was still using strcasestr:rolleyes:) I will try it on the 32.