fthis and content are both const char * and/or char *?
fthis and content are both const char * and/or char *?
Interesting. Using gcc 4.0.1 on Mac OSX (yeah, I know), this code:
produces these warnings/errors (with -Wall -Wextra):Code:#include <stdio.h> #include <string.h> int main(void) { char content[] = "A sample string."; char fthis[] = "Sample"; char *found; found = strcasestr(content, fthis); if (found != NULL) printf("%s\n", found); return 0; }
and runs correctly. Does it not for you?Code:
C programming resources:
GNU C Function and Macro Index -- glibc reference manual
The C Book -- nice online learner guide
Current ISO draft standard
CCAN -- new CPAN like open source library repository
3 (different) GNU debugger tutorials: #1 -- #2 -- #3
cpwiki -- our wiki on sourceforge
When you type "man strcasestr", what does it tell you the return type should be? (Since the warning is on the assignment, meaning your compiler thinks strcasestr returns an int, and not a char *, which means your header claims that strcasestr returns an int.) I guess you can go poking in your headers.
A little bit of googling shows that some headers surround it in #if __USE_GNU or something like that, which means that it's actually an implicit declaration rather than a mis-declaration. What happens if you add -std=gnu99 to your compile line?
MORE: If you want, you can doto see what happens in the pre-processor, and then look for "strcasestr" and see if a prototype got #included.Code:gcc -E -o temp.ohmygoodness temp.c
Last edited by tabstop; 10-11-2008 at 04:08 PM.
Nobody has ever pointed out that what you're trying to do is DEFINE a function (nested) inside a block. DECLARING one (i.e. prototyping it) is not a problem.
In other words, this is fine:
This is not:Code:void func1() { void func2(); func2(); }
Nested functions are not just unportable, they are gcc-specific and rely on trampolines to forward local variable scopes (i.e. they don't use "access pointers" because they break stack frame ABI compatibility) which means such a function takes huge performance hits when running in a non-executable-stack environment.Code:void func1() { void func2() { ... } func2(); }
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Well I guess fork() is out then, as that's not a C standard...
Compiler authors would not bother adding extensions if nobody was willing to use them. The Linux kernel, for instance, is only compilable by gcc due to mass use of gcc extensions. This is fine as long as you are comfortable with your decision, since you are locked in.
gcc, unlike most other compilers, is open source and unlikely to disappear overnight in a puff of smoke, so you won't be left with a mass of code that can't be compiled.
Of course, using an extension gratuitously doesn't make much sense. And in this specific case, I'd definitely stay away from nested functions, since believe me, you don't want to know what gcc is doing under the hood when you do that.
(gcc nested functions inherit the local scope of the enclosing function, meaning the nested function has access to the encloser's local variables -- the compiler must perform dirty tricks to make it happen correctly -- those tricks include putting CODE onto the STACK -- do you really want that?)
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}