Bug 152201 - cpp expands ifr_name
Summary: cpp expands ifr_name
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-26 01:46 UTC by keith adamson
Modified: 2007-11-30 22:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-26 08:25:58 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description keith adamson 2005-03-26 01:46:21 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050323 Firefox/1.0.2 Fedora/1.0.2-1

Description of problem:
Try to compile the following example:

$ cat foo.c
#include <sys/socket.h>
#include <netpacket/packet.h>
#include <net/ethernet.h>
#include <sys/ioctl.h>
#include <net/if.h>

int foo(char *ifr_name)

This is what I get:

$ gcc -c foo.c
foo.c:7: error: syntax error before '.' token

For some reason cpp expands ifr_name:

$ cpp foo.c | tail

extern void if_freenameindex (struct if_nameindex *__ptr) __attribute__ ((__nothrow__));

# 6 "foo.c" 2

int foo(char *ifr_ifrn.ifrn_name)

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

How reproducible:

Steps to Reproduce:
See description

Additional info:

Comment 1 keith adamson 2005-03-26 02:04:37 UTC
Did some more digging.  The bad include is:


Tried compiling the following and got same error:

$ cat foo.c
#include <net/if.h>

int foo(char *ifr_name)

This include belongs to:

$ rpm -q -f /usr/include/net/if.h

Comment 2 keith adamson 2005-03-26 02:20:06 UTC
Maybe this isn't a bug because I see a lot of namespace pollution in this
include file.  I thought that if the names were not documented then they would
start with an underscore(â_â).

From the include:

# define ifr_name       ifr_ifrn.ifrn_name      /* interface name       */
# define ifr_hwaddr     ifr_ifru.ifru_hwaddr    /* MAC address          */
# define ifr_addr       ifr_ifru.ifru_addr      /* address              */
# define ifr_dstaddr    ifr_ifru.ifru_dstaddr   /* other end of p-p lnk */
# define ifr_broadaddr  ifr_ifru.ifru_broadaddr /* broadcast address    */
# define ifr_netmask    ifr_ifru.ifru_netmask   /* interface net mask   */
# define ifr_flags      ifr_ifru.ifru_flags     /* flags                */
# define ifr_metric     ifr_ifru.ifru_ivalue    /* metric               */
# define ifr_mtu        ifr_ifru.ifru_mtu       /* mtu                  */
# define ifr_map        ifr_ifru.ifru_map       /* device map           */
# define ifr_slave      ifr_ifru.ifru_slave     /* slave device         */
# define ifr_data       ifr_ifru.ifru_data      /* for use by interface */
# define ifr_ifindex    ifr_ifru.ifru_ivalue    /* interface index      */
# define ifr_bandwidth  ifr_ifru.ifru_ivalue    /* link bandwidth       */
# define ifr_qlen       ifr_ifru.ifru_ivalue    /* queue length         */
# define ifr_newname    ifr_ifru.ifru_newname   /* New name             */

Are these documented anywhere in the man pages?

Comment 3 Jakub Jelinek 2005-03-26 08:12:48 UTC
Well, you are compiling without feature macros, so you can't talk about
namespace pollution.  The default namespace is not covered by standards,
so as you reported it, there is really not a bug.
ifr_* is not reserved namespace for net/if.h just on Linux, but e.g. Solaris
With -D_XOPEN_SOURCE=600, I agree there is a bug though,
doesn't include ifr_* for net/if.h and
doesn't speficy these.
So I wonder if
#ifdef __USE_MISC
in net/if.h shouldn't be changed to at least:
#if defined __USE_MISC && (!defined __USE_XOPEN2K || defined __USE_GNU)
or something like that.
Solaris guards these with
#if !defined(_XOPEN_SOURCE) || defined(__EXTENSIONS__)
but given that net/if.h header was not covered in Unix98, I think the above
should be enough.

Comment 4 Jakub Jelinek 2005-03-26 08:25:58 UTC
I shouldn't respond this early, the header is ok.
__USE_MISC is not defined for -D_XOPEN_SOURCE=600.
So there is no bug.

Comment 5 keith adamson 2005-03-26 16:32:47 UTC
Sorry for being an idiot, but why don't these reserved names show up in the man
page for "if.h" or in:


Is there any place to check the reserved namespaces for Linux and the libc
includes?  I've googled around without success.

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