Bug 150538 - Have to #undef read to build gnome-vfs2 with gcc 4
Summary: Have to #undef read to build gnome-vfs2 with gcc 4
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-vfs2
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: FC4Target
TreeView+ depends on / blocked
 
Reported: 2005-03-08 02:33 UTC by David Zeuthen
Modified: 2013-03-06 03:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-28 15:07:27 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Patch to make gnome-vfs2 build with gcc 4.0 (1.32 KB, patch)
2005-03-08 02:33 UTC, David Zeuthen
no flags Details | Diff

Description David Zeuthen 2005-03-08 02:33:25 UTC
Description of problem:

Have to '#undef read' in several places to get gnome-vfs2 to build since several
data structures has a function pointer called 'read'. The problem occurs when
code uses this function pointer; such as

 return tm->real_method->read(tm->real_method, method_handle,
                                     buffer, num_bytes, bytes_read_return,
                                     context);

Version-Release number of selected component (if applicable):

When building; using 

 gcc version 4.0.0 20050302 (Red Hat 4.0.0-0.31)

in the buildroot

How reproducible:

Always, on every arch.

Steps to Reproduce:

Attempt to rebuild gnome-vfs2 source RPM with gcc 4.0 (without the patch to
#undef read)
  
Actual results:

x86_64-redhat-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I.. -pthread
-DORBIT2=1 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
-I/usr/include/gconf/2 -I/usr/include/orbit-2.0
-I/usr/include/bonobo-activation-2.0 -I/usr/include/libbonobo-2.0
-I/usr/include/libxml2 -I/usr/kerberos/include -I/usr/include/howl-0.9.8
-DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/glib-2.0
-I/usr/lib64/glib-2.0/include -I/usr/include/hal -I/usr/include/dbus-1.0
-I/usr/lib64/dbus-1.0/include -DORBIT2=1 -pthread -I/usr/include/libbonobo-2.0
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/orbit-2.0
-I/usr/include/bonobo-activation-2.0 -DXDG_PREFIX=_gnome_vfs_xdg
-D_FILE_OFFSET_BITS=64 -D_BSD_SOURCE -D_LARGEFILE64_SOURCE
-D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -DG_DISABLE_DEPRECATED
-DDATADIR=\"/usr/share\" -DLIBDIR=\"/usr/lib64\" -DPREFIX=\"/usr\"
-DGNOMEVFS_LOCALEDIR=\"/usr/share/locale\" -DSYSCONFDIR=\"/etc\"
-DG_LOG_DOMAIN=\"libgnomevfs\" -I/usr/kerberos/include -O2 -Wall -g -pipe
-Wp,-D_FORTIFY_SOURCE=2 -m64 -c gnome-vfs-handle.c -MT gnome-vfs-handle.lo -MD
-MP -MF .deps/gnome-vfs-handle.TPlo  -fPIC -DPIC -o .libs/gnome-vfs-handle.o
gnome-vfs-handle.c:134:16: error: macro "read" passed 6 arguments, but takes just 3
gnome-vfs-handle.c: In function '_gnome_vfs_handle_do_read':
gnome-vfs-handle.c:132: error: incompatible types in assignment
gnome-vfs-handle.c: In function '_gnome_vfs_handle_do_tell':
gnome-vfs-handle.c:174: warning: pointer targets in passing argument 3 of
'handle->uri->method->tell' differ in signedness
make[1]: *** [gnome-vfs-handle.lo] Error 1
make[1]: Leaving directory
`/usr/src/build/536516-x86_64/BUILD/gnome-vfs-2.9.91/libgnomevfs'
make: *** [all] Error 2

Expected results:

This worked on gcc 3.4 so gcc itself or some standard library is #defining read
to be a macro?

Additional info:

Will attach patch that makes gnome-vfs2 build on gcc 4.0 by undefining read. I
realize this is a crude workaround. Please advise.

Comment 1 David Zeuthen 2005-03-08 02:33:26 UTC
Created attachment 111767 [details]
Patch to make gnome-vfs2 build with gcc 4.0

Comment 2 Jakub Jelinek 2005-03-08 08:41:53 UTC
This is gnome-vfs2 bug.  And FYI, it does have nothing to do with GCC 4.0.
POSIX explicitely allows read etc. to be defined as a function-like macro,
so if you want to use read for something else, you need either #undef read
(the bad solution) or use
return (tm->real_method->read) (tm->real_method, method_handle, buffer,
num_bytes, bytes_read_return, context);
or
return (*tm->real_method->read) (tm->real_method, method_handle, buffer,
num_bytes, bytes_read_return, context);
The #undef solution is bad, because you suddenly loose buffer overflow
protection for read.


Comment 3 David Zeuthen 2005-04-28 15:07:27 UTC
This is already fixed long time ago.


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