Closed Bug 285020 Opened 19 years ago Closed 19 years ago

invalid use of POSIX identifier 'recv' using -D_FORTIFY_SOURCE=2

Categories

(NSPR :: NSPR, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: caillon, Assigned: wtc)

Details

gcc -o prmwait.o -c    -Os -Wall -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -m32
-march=i386 -mtune=pentium4 -pipe -ansi -Wall -pthread -Os -Wall -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -m32 -march=i386 -mtune=pentium4 -fPIC  -UDEBUG
-DMOZILLA_CLIENT=1 -DNDEBUG=1 -DXP_UNIX=1 -D_POSIX_SOURCE=1 -D_BSD_SOURCE=1
-D_SVID_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1
-Di386=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -D_REENTRANT=1  -DFORCE_PR_LOG
-D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_
-I/usr/src/build/535150-i386/BUILD/mozilla/dist/include/nspr
-I../../../pr/include -I../../../pr/include/private  prmwait.c
prmwait.c:654:50: error: macro "recv" passed 5 arguments, but takes just 4
prmwait.c: In function '_MW_InitialRecv':
prmwait.c:652: warning: assignment makes integer from pointer without a cast


<@caillon> why am i able to compile this fine on my machine but not in beehive?
 this is failing on i386.
<@caillon>     652         desc->bytesRecv = desc->fd->methods->recv(
<@caillon>     653             desc->fd, desc->buffer.start,
<@caillon>     654             desc->buffer.length, 0, desc->timeout);
<@caillon> that's the code generating the error
<@mharris> caillon: gcc4 issue?
<@caillon> mharris, i'm using gcc4 locally
<@foo> caillon: if Jakub has added it already, recv is a macro now
<@foo> caillon: and the old rule applies: you annot use member names matching
any of the names of the official interfaces
<@foo> recv is a POSIX socket function, so as a name invalid
<@arjan> glibc "issue"
<@foo> as a struct element name
<@foo> arjan: we have now all commonly used functions which can read input an
attacker can control protected
<@foo> recv was part of this mass batch of changes
<@caillon> foo, so that is a glibc change?
<@arjan> foo: yeah recv needs to have buffer overflow protection indeed
<@foo> caillon: I assume, yes.  what glibc is in the build roots
<@arjan> caillon: it's allowed to do so by the standards tho
<@caillon> > latest-pkg dist-fc4 glibc
<@caillon>
/mnt/redhat/beehive/comps/dist/fc4/glibc/2.3.4-12/SRPMS/glibc-2.3.4-12.src.rpm
<@arjan> a gross hack would be to undefine recv macro in your build macros
<@caillon> i'm just using glibc-2.3.4-10
<@foo> caillon: I don't have -12 here yet, but it presumably has the header changes
<@foo> caillon: for now, use desc->bytesRecv = (desc->fd->methods->recv)(...
<@foo> i.e., wrap the member access in parenthesis
Note this is triggered by using the FORTIFY_SOURCE=2 flag, which will be the
default in FC4.
Summary: invalid use of POSIX identifier 'recv' → invalid use of POSIX identifier 'recv' using -D_FORTIFY_SOURCE=2
r=wtc.

I checked in the patch suggested by "foo" on the
NSPR tip (NSPR 4.6) and NSPRPUB_PRE_4_2_CLIENT_BRANCH
(Mozilla 1.8 Beta 2).
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → 4.6
You need to log in before you can comment on or make changes to this bug.