Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 82594 - C++ programs using getsockname and socklen_t fail
Summary: C++ programs using getsockname and socklen_t fail
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: High major (vote)
Assignee: Gentoo Toolchain Maintainers
URL: http://www.fefe.de/getsockname.c
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-19 10:02 UTC by Felix von Leitner
Modified: 2005-12-11 18:26 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix von Leitner 2005-02-19 10:02:16 UTC
I wrote a small program calling getsockname on a struct sockaddr_storage.
When compiling it as a C program, and running strace on it, I get

  getsockname(0, 0x7fbffff250, [128])     = -1 ENOTSOCK (Socket operation on non-s

renaming from .c to .C and compiling it as C++, I get

  getsockname(0, 0x7fbffff250, [13835043761631002752]) = -1 ENOTSOCK (Socket operation on non-socket)

I found this because I have weird problems running psi on my amd64 box, so I ran strace on it.  I'm not sure this is really the problem.

Reproducible: Always
Steps to Reproduce:
1. wget http://www.fefe.de/getsockname.c
2. ln -s getsockname.c getsockname.C
3. gcc -o working getsockname.c
4. g++ -o broken getsockname.C
5. strace -egetsockname ./working
6. strace -egetsockname ./broken

Actual Results:  
getsockname(0, 0x7fbffff240, [128])     = -1 ENOTSOCK (Socket operation on
non-socket)
getsockname(0, 0x7fbffff240, [13835043692911526016]) = -1 ENOTSOCK (Socket
operation on non-socket)


Expected Results:  
getsockname(0, 0x7fbffff240, [128])     = -1 ENOTSOCK (Socket operation on
non-socket)
getsockname(0, 0x7fbffff240, [128])     = -1 ENOTSOCK (Socket operation on
non-socket)

Portage 2.0.51-r15 (default-linux/amd64/2004.3, gcc-3.4.3,
glibc-2.3.4.20050125-r0, 2.6.10-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.10-gentoo-r6 x86_64 unknown
Gentoo Base System version 1.6.9
Python:              dev-lang/python-2.3.5 [2.3.5 (#1, Feb 19 2005, 17:28:03)]
dev-lang/python:     2.3.5
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.5, 1.7.9-r1, 1.6.3, 1.4_p6, 1.9.4, 1.8.5-r3
sys-devel/binutils:  2.15.92.0.2-r2
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CFLAGS="-pipe -Os"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env
/usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks notitles sandbox userpriv
usersandbox"
GENTOO_MIRRORS="http://pandemonium.tiscali.de/pub/gentoo/
http://ftp.uni-erlangen.de/pub/mirrors/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.de.gentoo.org/gentoo-portage"
USE="amd64 X aac acpi alsa berkdb bitmap-fonts bzlib cdb cdr crypt curl dvb dvd
dvdr encode exif f77 fam flac font-server fortran ftp gif gmp gpm gtk gtk2
gtkhtml imagemagick ipv6 jabber jp2 jpeg kde lzw lzw-tiff mad maildir mmap motif
mozilla multilib ncurses netboot nodrm nptl nptlonly offensive ogg oggvorbis
opengl oss pam png posix qt readline slang sockets speex spell ssl theora tiff
truetype truetype-fonts type1-fonts usb userlocales xml2 xpm xrandr xv xvid zlib"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
Comment 1 Felix von Leitner 2005-02-19 10:17:00 UTC
It turns out that the generated assembly code is identical.

Still the result differs.  So it's either a bug in the C++ startup code (?!) or maybe strace is mysteriously broken.

The binaries differ by the ldd output: the C++ version also links libstdc++.so.6, libm.so.6 and libgcc_s.so.1 in.
Comment 2 Mark Loeser (RETIRED) gentoo-dev 2005-12-11 18:26:59 UTC
Is this still a problem with the newest stable version of GCC?  The two seem to
behave the same to me.