Printable View
Is there anything wrong with declaring a function inside a forked block, eg:
it seems to work, but just because no one stopped you doesn't make it right -- so I thought I'd ask and find out what kind of trouble may await.Code:pid=fork();
if (pid==0) {
void newfunc() {
[....]
}
[...]
newfunc();
}
EDIT: Wrong thread.
It's nothing to do with fork, it's just illegal C code.
C doesn't allow nested functions, you're relying on a gcc extension.
So as long as it's compiled on gcc that's okay?Quote:
Originally Posted by Salem
No, don't rely on it.
Local functions are illegal both in C and C++ and frankly, I don't see it as good solution to anything - even if allowed.
You should write standard and portable code, first and foremost, without extensions.
Why not use a legal construct?
ggCode:typedef void (*fork_func)(void);
pid_t fork_run(fork_func pfn)
{
pid_t pid = fork();
if (pid == 0)
pfn();
return pid;
}
Well, gcc being my sole compiler, I wasn't aware I was using an extension (and without digging, I'm not really sure what one is). The reason for it is that the child performs operations on it's own variables, and I can't declare the function outside the child unless I globalize those variables. So perhaps it's just about tidyness. But suddenly I wonder -- is it also illegal to nest variable declarations that way?Quote:
Originally Posted by Elysia
Code:pid=fork();
if (pid==0) {
int x;
char y;
}
declaring variables at the top of any block is legal.Code:void func()
{
/* code */
{
int x, y; /* legal */
/* code */
} /* x and y go out of scope here */
}
> Well, gcc being my sole compiler, I wasn't aware I was using an extension (and without digging, I'm not really sure what one is).
gcc -W -Wall -ansi -pedantic prog.c
Will tell you most things which are non-portable.
> But suddenly I wonder -- is it also illegal to nest variable declarations that way?
So long as they're the first thing inside any enclosing brace, that's just fine.
> The reason for it is that the child performs operations on it's own variables, and I can't declare the function outside the child unless I globalize those variables.
The scope of your variables doesn't matter.
As soon as you fork(), you've got your own separate copies no matter what scope they're declared in.
C99 and C++ does not have the restriction that variables must be at the start of a block anyway. You don't need to follow the poor ruleset of C89. GCC fully supports C99, too.
Partial support, actually. http://gcc.gnu.org/gcc-4.3/c99status.html
Oh well, better than nothing, at least.
Interesting. The nested function is just a warning.Quote:
Originally Posted by Salem
One of the repeated warnings in this which is sort of befuddling is:
warning: too many arguments for format
Because I have three arguments to sprintf. How should I take that?
> Interesting. The nested function is just a warning.
Add -Werror
Code?
warning: too many arguments for format
So subtle... if only gcc would output it more like this
warning: too many arguments for format
It means you are doing something like:
Surely it isn't as bad as doing this:Code:sprintf("%d %d", &x, &y, &z);
But it means you likely copied and pasted carelessly, or your logic somehow got muddled during the code writing process.Code:sprintf("%d %d %d", &x, &y);
Absolutely not my friend. Here is the exact lineQuote:
Originally Posted by master5001
sprintf(messg,"Can't unlink %s",sckt);
Where is the extra argument???
sprintf(messg,"Can't unlink %s",sckt);
Careful on those, MK27. Its a mistake all of us can easily make. Remember that printf() works with the output buffer. sprint() is the one that prints to strings.
Even at that, I would recommend using snprintf(). Which helps prevent buffer overflows.
Remember, only you can prevent buffer overflows.
I bet.Quote:
Originally Posted by master5001
Does this mean I am a prisoner of GNU forever?Code:Function: int sprintf (char *s, const char *template, ...)
This is like printf, except that the output is stored in the character array s
instead of written to a stream. A null character is written to mark the end of the string.
MK27 can you post a compilable snippet?
of what?Quote:
Originally Posted by robwhit
ps. it wasn't a scoping issue
Of your sprintf problem.
I didn't understand that there was one.Quote:
Originally Posted by robwhit
Umm... ok...
Well, obviously there is one since you get a warning?
And btw master5001, you know there's an edit button, right? ;)
No. For example, my compiler (gcc 4.1.2) gives an "assignment makes pointer from integer without a cast" warning whenever strcasestrQuote:
Originally Posted by Elysia
is used, no matter how -- guarrenteed. That's an erroneous warning.
(master5001 knows this and would fancy himself a mindf#@er)
Yeah but I was hungry and ready to head home... So I figured people would overlook my spamming.Quote:
Originally Posted by Elysia
Not at all. sprintf() is a C standard function. strcasestr() on the otherhand is a GNU extention. I use it anyway... Microsoft provides a lot of functions similar to the GNU extentions that one can simply #define as the GNU names of the functions. I know that is not your issue, MK27. But there are a lot of M$ folks floating around.Quote:
Originally Posted by MK27
Can you post an example of code that gives you that error reguardless? Por favor.
[edit]Hey, are you trying to pass a socket as a string? That would issue a warning too. Though typically it would not be this specific warning.[/edit]
found = strcasestr(content, fthis);Quote:
Originally Posted by master5001
But gcc is a GNU compiler...
A filename that aspires to sockethood.Quote:
Originally Posted by master5001
And how are content, fthis and found declared?
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:
It runs correctly, but it produces this warning:Quote:
Originally Posted by tabstop
If you substitute strstr there is no warning.Code:test.c: In function ‘main’:
test.c:8: warning: assignment makes pointer from integer without a cast
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
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();
}
Well I guess fork() is out then, as that's not a C standard... ;)Quote:
Originally Posted by Elysia
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?)