Received: by 2002:ac0:950e:0:0:0:0:0 with SMTP id f14csp37784imc; Fri, 15 Mar 2019 14:22:17 -0700 (PDT) X-Google-Smtp-Source: APXvYqz2tbJkwcy259XvEOfuZQq7I12SQxYmOdsM1Gj7eiCoM/lMpRHNWkDeeQwZZzpmaiHPkqi/ X-Received: by 2002:a63:5321:: with SMTP id h33mr5429836pgb.168.1552684937088; Fri, 15 Mar 2019 14:22:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552684937; cv=none; d=google.com; s=arc-20160816; b=stkkJSGGMXSXLwGbEqk/pX7Z1FRZluFLZyJbKXCS9NrJdtUrsF6yaOwq3NlBrUFqFG yJyqM5xCAdMHNmJ/mBr9RI0S0lxFicDrIxMebGlf9xQ3gN4KQ8u3CCLcnrIyVO8AbkA2 k9tIHTrSCHHGRuQLthqjaJ/QmlhpHQRvUN0XTKI7K/381EdEKRPfHExP1zmncgx3TUWj p+F+wsKqfCxEZEnNoBIXtp9oaQhC99/GDZdDNQm24xA4/X54pVLINl/2jlY/fysLhbtg T8pcjbT+12Bii5sfNT3pgqa6WB8Kh9qKO3TlFq0sJ/os4OfRUKUSl5PEZ/30r4Z5zzNG EdOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:in-reply-to:date :references:subject:cc:to:from; bh=D9mt44EwoTwZPnrsEtGDAeaW2lscvKKrmSC5RWYUCGo=; b=hPDWf0gjULDN4mFZ5Sv5GsvfX/4wcYjzuE8wBwyKdajpMbXhk6ynEKbZ+CCYEvJ310 V4DQU2Mc02wBc1lv6bAFiFENUswU8qDQEvml0eLoxwP8MAQT0Na7fNok/rMUWd1EaAbh caEiZtJYbISoIjP8nsJbkeXloKZ08vbnOMhD1XYuBNxzFye6fAKt4K4vDXQJbilhynF5 IbcSnk3KeN7qLFfwt4ck1LX5KWV+YlGLKcco8+9ymrZEACIR4xrFpHOrQNp+yLEJRAUK 6h8qxKoRLML4kX7DjALZ933O/m1yHbe6w9XzopsEhM1XO2LD+GN+NO2q1MxItmM/qf80 /hPw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e9si2801421plb.99.2019.03.15.14.22.01; Fri, 15 Mar 2019 14:22:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726691AbfCOVUM (ORCPT + 99 others); Fri, 15 Mar 2019 17:20:12 -0400 Received: from albireo.enyo.de ([5.158.152.32]:58866 "EHLO albireo.enyo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726213AbfCOVUL (ORCPT ); Fri, 15 Mar 2019 17:20:11 -0400 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1h4uFI-0001AG-95; Fri, 15 Mar 2019 21:20:04 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.89) (envelope-from ) id 1h4uFI-0001RH-2d; Fri, 15 Mar 2019 22:20:04 +0100 From: Florian Weimer To: Arnd Bergmann Cc: "David S . Miller" , Deepa Dinamani , Willem de Bruijn , alpha , linux-arch , linux-mips@vger.kernel.org, Parisc List , sparclinux , Laura Abbott , Networking , Linux Kernel Mailing List , Linux API Subject: Re: [PATCH] y2038: fix socket.h header inclusion References: <20190311153857.563743-1-arnd@arndb.de> <87k1h1fgkk.fsf@mid.deneb.enyo.de> Date: Fri, 15 Mar 2019 22:20:04 +0100 In-Reply-To: (Arnd Bergmann's message of "Fri, 15 Mar 2019 21:30:25 +0100") Message-ID: <87a7hvded7.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Arnd Bergmann: > On Thu, Mar 14, 2019 at 7:41 PM Florian Weimer wrote: >> >> * Arnd Bergmann: >> >> > 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 >> > #include >> > -#include >> >> This breaks POSIX conformance in glibc because the >> 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 header file. Similarly for val. Since glibc pulls in 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 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 still uses val, so that part of the issue remains.