This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Ping Re: Fix bits/socket.h IOC* namespace issues (bug 21267)

From: Joseph Myers <joseph at codesourcery dot com>
To: Arnd Bergmann <arnd at arndb dot de>
Cc: GNU C Library <libc-alpha at sourceware dot org>
Date: Mon, 27 Mar 2017 14:46:33 +0000
Subject: Re: Ping Re: Fix bits/socket.h IOC* namespace issues (bug 21267)
Authentication-results: sourceware.org; auth=none
References: <alpine.DEB.2.20.1703180031310.9823@digraph.polyomino.org.uk> <alpine.DEB.2.20.1703231758480.21959@digraph.polyomino.org.uk> <CAK8P3a2i9megdoUEnreiXiyt1DJ8P+meprN=vi2Z3nYtO3HwmQ@mail.gmail.com>

On Fri, 24 Mar 2017, Arnd Bergmann wrote:

> There are many exported or user-space provided headers that include
> linux/ioctl.h or asm/ioctl.h in order to get the _IOC/IOW/IOR/IOWR
> macros:

That's what I expect them to be used for.

> so any of them will also pull in IOC_IN/INOUT/OUT.  Is mips/asm/sockios.h
> the only one in that list that i  problematic for glibc, or should they
> all avoid the  macros if possible?

Only mips/asm/sockios.h is currently observed to cause namespace problems.  
alpha's asm/sockios.h also uses _IOR/_IOW macros, but without including 
<asm/ioctl.h> (so I suppose the macros defined using _IOR/_IOW might not 
actually work unless a source of those macro definitions gets included 
explicitly).

-- 
Joseph S. Myers
joseph@codesourcery.com

References:
- Fix bits/socket.h IOC* namespace issues (bug 21267)
  - From: Joseph Myers
- Ping Re: Fix bits/socket.h IOC* namespace issues (bug 21267)
  - From: Joseph Myers
- Re: Ping Re: Fix bits/socket.h IOC* namespace issues (bug 21267)
  - From: Arnd Bergmann

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]