git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Fix gcc-4 warning in accept() call
@ 2005-09-29 21:05 Pavel Roskin
  2005-09-29 23:11 ` Horst von Brand
  2005-09-30  5:49 ` Junio C Hamano
  0 siblings, 2 replies; 8+ messages in thread
From: Pavel Roskin @ 2005-09-29 21:05 UTC (permalink / raw)
  To: git

Fix gcc-4 warning in accept() call

gcc-4 warns about sign mismatch in pointers.  Third argument in accept()
is socklen_t, which is unsigned.  Since Linus doesn't like socklen_t
(see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
unsigned int.

Signed-off-by: Pavel Roskin <proski@gnu.org>

diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -459,7 +459,7 @@ static int serve(int port)
 
 			if (FD_ISSET(sockfd, &fds)) {
 				struct sockaddr_storage ss;
-				int sslen = sizeof(ss);
+				unsigned int sslen = sizeof(ss);
 				int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
 				if (incoming < 0) {
 					switch (errno) {


-- 
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-29 21:05 [PATCH] Fix gcc-4 warning in accept() call Pavel Roskin
@ 2005-09-29 23:11 ` Horst von Brand
  2005-09-30  4:09   ` Pavel Roskin
  2005-09-30  5:49 ` Junio C Hamano
  1 sibling, 1 reply; 8+ messages in thread
From: Horst von Brand @ 2005-09-29 23:11 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: git

Pavel Roskin <proski@gnu.org> wrote:
> Fix gcc-4 warning in accept() call
> 
> gcc-4 warns about sign mismatch in pointers.  Third argument in accept()
> is socklen_t, which is unsigned.  Since Linus doesn't like socklen_t
> (see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
> unsigned int.
> 
> Signed-off-by: Pavel Roskin <proski@gnu.org>
> 
> diff --git a/daemon.c b/daemon.c
> --- a/daemon.c
> +++ b/daemon.c
> @@ -459,7 +459,7 @@ static int serve(int port)
>  
>  			if (FD_ISSET(sockfd, &fds)) {
>  				struct sockaddr_storage ss;
> -				int sslen = sizeof(ss);
> +				unsigned int sslen = sizeof(ss);

Shouldn't this be size_t?

>  				int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
>  				if (incoming < 0) {
>  					switch (errno) {
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-29 23:11 ` Horst von Brand
@ 2005-09-30  4:09   ` Pavel Roskin
  2005-09-30  4:46     ` H. Peter Anvin
  0 siblings, 1 reply; 8+ messages in thread
From: Pavel Roskin @ 2005-09-30  4:09 UTC (permalink / raw)
  To: Horst von Brand; +Cc: git

Quoting Horst von Brand <vonbrand@inf.utfsm.cl>:

> > +				unsigned int sslen = sizeof(ss);
>
> Shouldn't this be size_t?

No.  That would actually break things on big-endian 64-bit platforms.

You can see "info libc" for the whole story.  My (limited!) understanding is
that it should be 32-bit for compatibility reasons, so socklen_t was a trick to
fool size_t proponents from the POSIX committee :-)

--
Regards,
Pavel Roskin

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-30  4:09   ` Pavel Roskin
@ 2005-09-30  4:46     ` H. Peter Anvin
  0 siblings, 0 replies; 8+ messages in thread
From: H. Peter Anvin @ 2005-09-30  4:46 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: Horst von Brand, git

Pavel Roskin wrote:
> Quoting Horst von Brand <vonbrand@inf.utfsm.cl>:
> 
> 
>>>+				unsigned int sslen = sizeof(ss);
>>
>>Shouldn't this be size_t?
> 
> 
> No.  That would actually break things on big-endian 64-bit platforms.
> 
> You can see "info libc" for the whole story.  My (limited!) understanding is
> that it should be 32-bit for compatibility reasons, so socklen_t was a trick to
> fool size_t proponents from the POSIX committee :-)
> 

Formally it should be "socklen_t" or "int".  It should *not* be 
"unsigned int"!

	-hpa

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-29 21:05 [PATCH] Fix gcc-4 warning in accept() call Pavel Roskin
  2005-09-29 23:11 ` Horst von Brand
@ 2005-09-30  5:49 ` Junio C Hamano
  2005-09-30  5:53   ` H. Peter Anvin
  1 sibling, 1 reply; 8+ messages in thread
From: Junio C Hamano @ 2005-09-30  5:49 UTC (permalink / raw)
  To: Pavel Roskin; +Cc: git

Pavel Roskin <proski@gnu.org> writes:

> gcc-4 warns about sign mismatch in pointers.  Third argument in accept()
> is socklen_t, which is unsigned.  Since Linus doesn't like socklen_t
> (see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
> unsigned int.

Based on the list comments, I'd drop this patch -- it appears
that gcc-4 warning is useless in this case.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-30  5:49 ` Junio C Hamano
@ 2005-09-30  5:53   ` H. Peter Anvin
  2005-09-30  5:58     ` H. Peter Anvin
  0 siblings, 1 reply; 8+ messages in thread
From: H. Peter Anvin @ 2005-09-30  5:53 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Pavel Roskin, git

Junio C Hamano wrote:
> Pavel Roskin <proski@gnu.org> writes:
> 
> 
>>gcc-4 warns about sign mismatch in pointers.  Third argument in accept()
>>is socklen_t, which is unsigned.  Since Linus doesn't like socklen_t
>>(see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
>>unsigned int.
> 
> Based on the list comments, I'd drop this patch -- it appears
> that gcc-4 warning is useless in this case.
> 

No, it's not.  The proper type, if you don't use socklen_t, is int, not 
unsigned int.

	-hpa

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-30  5:53   ` H. Peter Anvin
@ 2005-09-30  5:58     ` H. Peter Anvin
  2005-09-30  6:21       ` Junio C Hamano
  0 siblings, 1 reply; 8+ messages in thread
From: H. Peter Anvin @ 2005-09-30  5:58 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Junio C Hamano, Pavel Roskin, git

H. Peter Anvin wrote:
> Junio C Hamano wrote:
> 
>> Pavel Roskin <proski@gnu.org> writes:
>>
>>
>>> gcc-4 warns about sign mismatch in pointers.  Third argument in accept()
>>> is socklen_t, which is unsigned.  Since Linus doesn't like socklen_t
>>> (see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
>>> unsigned int.
>>
>>
>> Based on the list comments, I'd drop this patch -- it appears
>> that gcc-4 warning is useless in this case.
>>
> 
> No, it's not.  The proper type, if you don't use socklen_t, is int, not 
> unsigned int.
> 

Apparently I'm wrong; socklen_t is unsigned int at least on glibc for 
i386.  I'll shut up now.

	-hpa

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] Fix gcc-4 warning in accept() call
  2005-09-30  5:58     ` H. Peter Anvin
@ 2005-09-30  6:21       ` Junio C Hamano
  0 siblings, 0 replies; 8+ messages in thread
From: Junio C Hamano @ 2005-09-30  6:21 UTC (permalink / raw)
  To: H. Peter Anvin; +Cc: Pavel Roskin, git

"H. Peter Anvin" <hpa@zytor.com> writes:

> Apparently I'm wrong; socklen_t is unsigned int at least on glibc for 
> i386.  I'll shut up now.

Ah, I should shut up too.  Thanks for checking what we should
use.

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-09-30  6:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-09-29 21:05 [PATCH] Fix gcc-4 warning in accept() call Pavel Roskin
2005-09-29 23:11 ` Horst von Brand
2005-09-30  4:09   ` Pavel Roskin
2005-09-30  4:46     ` H. Peter Anvin
2005-09-30  5:49 ` Junio C Hamano
2005-09-30  5:53   ` H. Peter Anvin
2005-09-30  5:58     ` H. Peter Anvin
2005-09-30  6:21       ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).