Bug 3387 - getsockname/getpeername do not follow the BSD standard
Summary: getsockname/getpeername do not follow the BSD standard
Status: REJECTED INVALID
Alias: None
Product: Networking
Classification: Unclassified
Component: Other (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Hideaki YOSHIFUJI
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-09-13 08:47 UTC by Ioannis Aslanidis
Modified: 2004-09-21 03:36 UTC (History)
0 users

See Also:
Kernel Version: 2.6.*
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
This is the headers file for gso.cpp (362 bytes, text/plain)
2004-09-13 08:51 UTC, Ioannis Aslanidis
Details
This is a sample source code that reproduces the bug (requires the header file) (1.92 KB, text/plain)
2004-09-13 08:53 UTC, Ioannis Aslanidis
Details

Description Ioannis Aslanidis 2004-09-13 08:47:09 UTC
This bug report follows bug http://sources.redhat.com/bugzilla/show_bug.cgi?
id=345

Distribution: Gentoo (2.6.*) & Debian (2.6.*)
Hardware Environment: x86 (Pentium IV & Athlon XP)
Problem Description:

The funcions getsockname and getpeername are supposed to return 0 when 
successfull and different than 0 when erroneous. I thought it was a fault in 
the glibc library so I reported it there, but the answer I had was: 

------- Additional Comment #5 From Ulrich Drepper 2004-09-12 05:49 [reply] ----
--- 
getsockname in glibc is nothing but a syscall wrapper.  If you have a problem,
this is a problem in the kernel.  Report the bug appropriately.

BTW, the BSD Standard (man 2 getsockname):

GETSOCKNAME(2)                                                            
Linux Programmer's 
Manual                                                            GETSOCKNAME
(2)

NAME
       getsockname - get socket name

SYNOPSIS
       #include <sys/socket.h>

       int getsockname(int s, struct sockaddr *name, socklen_t *namelen);

DESCRIPTION
       Getsockname  returns  the  current name for the specified socket.  The 
namelen parameter should be initialized to indicate the amount of space 
pointed to by name.  On
       return it contains the actual size of the name returned (in bytes).

RETURN VALUE
       On success, zero is returned.  On error, -1 is returned, and errno is 
set appropriately.

ERRORS
       EBADF  The argument s is not a valid descriptor.

       ENOTSOCK
              The argument s is a file, not a socket.

       ENOBUFS
              Insufficient resources were available in the system to perform 
the operation.

       EFAULT The name parameter points to memory not in a valid part of the 
process address space.

CONFORMING TO
       SVr4, 4.4BSD (the getsockname function call appeared in 4.2BSD).  SVr4 
documents additional ENOMEM and ENOSR error codes.

NOTE
       The third argument of getsockname is in reality an `int *' (and this is 
what BSD 4.* and libc4 and  libc5  have).   Some  POSIX  confusion  resulted  
in  the  present
       socklen_t.  The draft standard has not been adopted yet, but glibc2 
already follows it and also has socklen_t. See also accept(2).

SEE ALSO
       bind(2), socket(2)

BSD Man 
Page                                                                      1993-
07-24                                                                   
GETSOCKNAME(2)
Comment 1 Ioannis Aslanidis 2004-09-13 08:51:23 UTC
Created attachment 3663 [details]
This is the headers file for gso.cpp
Comment 2 Ioannis Aslanidis 2004-09-13 08:53:29 UTC
Created attachment 3664 [details]
This is a sample source code that reproduces the bug (requires the header file)

This file and gso.h reproduce the bug. Compile simply and check the code.
You'll notice that it returns != 0 while errno tells successful. Additionally I
have tested this with some servers, like google.com, by connecting to port 80
and getting the IP addresses of both sides correctly.
Comment 3 Hideaki YOSHIFUJI 2004-09-21 00:47:18 UTC
Kernel is not responsible to errno, but glibc is;
it should setup errno appropriately returned from syscall.
Comment 4 Hideaki YOSHIFUJI 2004-09-21 00:48:28 UTC
Please report this to the appropriate community (glibc).
Comment 5 Ioannis Aslanidis 2004-09-21 03:36:33 UTC
Please, stop bouncing this bug.

glibc sent me to you and you send me back to them.

I start getting tired of this situation.

Reported back to: http://sources.redhat.com/bugzilla/show_bug.cgi?id=345

Note You need to log in before you can comment on or make changes to this bug.