* Arnd Bergmann:
On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer [off-list ref] wrote:
quoted
* Arnd Bergmann:
quoted
diff --git a/arch/alpha/include/uapi/asm/socket.h
b/arch/alpha/include/uapi/asm/socket.h
index 0d0fddb7e738..976e89b116e5 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -2,8 +2,8 @@
#ifndef _UAPI_ASM_SOCKET_H
#define _UAPI_ASM_SOCKET_H
+#include <linux/posix_types.h>
#include <asm/sockios.h>
-#include <asm/bitsperlong.h>
This breaks POSIX conformance in glibc because the
<linux/posix_types.h> header is not namespace clean. It contains the
identifiers fds_bits and val:
unsigned long fds_bits[__FD_SETSIZE / (8 * sizeof(long))];
int val[2];
What is problematic about the struct members here? I had thought that
only the struct names have to be in a namespace to be usable here,
but not the members.
According POSIX, a user can do this:
#define fds_bits 1024
before including the <sys/socket.h> header file. Similarly for val.
Since glibc pulls in <asm/socket.h> indirectly, the result is a parse
error, even though the programmer did nothing wrong (fds_bits is not
an identifier used by POSIX, nor is it in the implementation
namespace, ans <sys/socket.h> is a POSIX header).
We could use asm/posix_types.h instead of linux/posix_types.h,
would that address your concern?
It should fix the fds_bits case, I think. But
<asm-generic/posix_types.h> still uses val, so that part of the issue
remains.