11 Nov, 2011, absolute_asylum wrote in the 1st comment:
Votes: 0
comm.c:1006: warning: pointer targets in passing argument 3 of getsockname dif
comm.c:1007: warning: pointer targets in passing argument 3 of accept differ i
comm.c:1048: warning: pointer targets in passing argument 3 of getpeername dif

(line 1006) getsockname( control, (struct sockaddr *) &sock, &size );
(line 1007) if ( ( desc = accept( control, (struct sockaddr *) &sock, &size) ) < 0 )
(line 1048) if ( getpeername( desc, (struct sockaddr *) &sock, &size ) < 0 )


I do not know why all of a sudden this appeared, seeing never touching this part of the code, and compiled clean before…I have replaced it 3 times and still comes up with this error…
11 Nov, 2011, quixadhal wrote in the 2nd comment:
Votes: 0
Silly C. :)

What is size declared as? The function would like it to be a socklen_t variable.
11 Nov, 2011, Rarva.Riendf wrote in the 3rd comment:
Votes: 0
Sometimes with a gdb upgrade some stuff it happily let slip by get a warning. That usually means a potential problem was totally ignored before, now you get a warning.
11 Nov, 2011, Runter wrote in the 4th comment:
Votes: 0
Or it means that the non-problems of today are considered something you should be warned about tomorrow. There's a reason it's a warning and not an error. A bigger problem to me is the notion that code that compiles clean is somehow superior to code that has warnings.

To me, warnings are a good source of investigation. They're not something I care about "shutting up" with code changes if the code is fine. People who care so much about warnings should be reminded that not only do you get different warnings in different versions of gcc. You get different warnings for different compilers in general.
11 Nov, 2011, Rarva.Riendf wrote in the 5th comment:
Votes: 0
Runter said:
A bigger problem to me is the notion that code that compiles clean is somehow superior to code that has warnings.

We all agree it is not, but it all depends on what was done to (fix) the warning.
When gcc complains about a break missing, even it if the last one, putting it will not render the code ugly to read. Though when you have to (char) cast everywhere it complains it is ugly.

But is is superiour in one respect: all the next warning are yours, and easier to spot this way. It does not mean you have to 'fix' them, but you can add an ignore tagg and explain why you did. I had to do it for numerous switch break case as an example when it warned a break 'may' miss.
11 Nov, 2011, Runter wrote in the 6th comment:
Votes: 0
Why would I 'fix' something that isn't broken? I'll leave that to you folks who think you need gcc's blessing when writing completely valid C.
11 Nov, 2011, Rarva.Riendf wrote in the 7th comment:
Votes: 0
Runter said:
Why would I 'fix' something that isn't broken? I'll leave that to you folks who think you need gcc's blessing when writing completely valid C.

I did not said that fix means changing code, I said a fix could simply be to add an ignore code to the warning. There is a reason those exists. It is so you dont have to sort all the warnings to see if there is a new one you should pay attention to.
Be considerate to the next one having to fix/expand your code….he does not know why he should ignore all the warnings…
11 Nov, 2011, Vigud wrote in the 8th comment:
Votes: 0
If you're fine with the fact that your C code works by accident, then you don't have to investigate the issue. I understand people who want to have a life.
11 Nov, 2011, Rarva.Riendf wrote in the 9th comment:
Votes: 0
I fear a renact of another thread on the same subject :) I will pass.
11 Nov, 2011, David Haley wrote in the 10th comment:
Votes: 0
What if you can have a life all the while writing correct code? Maybe y'all can't do both, but y'all should speak for yourselves. :wink:
12 Nov, 2011, Runter wrote in the 11th comment:
Votes: 0
David Haley said:
What if you can have a life all the while writing correct code? Maybe y'all can't do both, but y'all should speak for yourselves. :wink:


I prefer you'all.
12 Nov, 2011, quixadhal wrote in the 12th comment:
Votes: 0
Maybe you'all should just use perl. It's less whiny than gcc. :)
12 Nov, 2011, Tyche wrote in the 13th comment:
Votes: 0
absolute_asylum said:
I do not know why all of a sudden this appeared, seeing never touching this part of the code, and compiled clean before…I have replaced it 3 times and still comes up with this error…


Not an error, a warning.

http://pubs.opengroup.org/onlinepubs/790...
"<sys/socket.h> makes available a type, socklen_t, which is an unsigned opaque integral type of length of at least 32 bits. To forestall portability problems, it is recommended that applications should not use values larger than 2^32 - 1."

It's warning that you are passing a pointer to signed int, rather than an unsigned int.
You can change the type of the variable, size, to socklen_t,
or, in this particular case, you can also safely ignore the warnings.
0.0/13