From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24457 invoked by alias); 18 Apr 2018 18:40:35 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 24442 invoked by uid 89); 18 Apr 2018 18:40:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_MANYTO,SPF_PASS autolearn=no version=3.3.2 spammy= X-HELO: mailbackend.panix.com X-Gm-Message-State: ALQs6tDTLSftbTphb0jRSGn1xYIlJrmxw5DwWuZ0dqoq2p4xlhDv+iL4 a32O9Fna7B6GtZIWv33PEBSG6Pe1W8b7UTpnm3w= X-Google-Smtp-Source: AIpwx4+BridpI33vkoZsq0nTNGU5Ublo9Yh6fpWsJLTnceK0LN1KZdZIqYNKzbLxlTkhxQ5mpTy36VKFyN/WjQFc5o8= X-Received: by 2002:aca:efd5:: with SMTP id n204-v6mr1898316oih.41.1524076829812; Wed, 18 Apr 2018 11:40:29 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20180418140322.642wjpqax3gjfp6j@var.youpi.perso.aquilenet.fr> References: <20180402001003.3u5n2p5pdmv4hos5@var.youpi.perso.aquilenet.fr> <20180402155017.iermidp5siqgcixv@var.youpi.perso.aquilenet.fr> <20180402161347.e5nx7cdt7pkgx52u@var.youpi.perso.aquilenet.fr> <20180417225015.56yv5wktzcx75srk@var.youpi.perso.aquilenet.fr> <20180417230835.pa5a3lvoudjyt4gy@var.youpi.perso.aquilenet.fr> <20180418140322.642wjpqax3gjfp6j@var.youpi.perso.aquilenet.fr> From: Zack Weinberg Date: Wed, 18 Apr 2018 18:40:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Upstreaming the glibc Hurd port To: Zack Weinberg , Joseph Myers , Florian Weimer , Thomas Schwinge , GNU C Library , bug-hurd@gnu.org, David Michael Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-04/txt/msg00317.txt.bz2 On Wed, Apr 18, 2018 at 10:03 AM, Samuel Thibault wrote: >> >> I have a concern: the types 'struct sched_param' and 'struct >> __sched_param' are not compatible, even if their members are identical >> (6.2.7p1 explicitly requires the tags to be the same for >> compatibility). > > Ah, probably that's why bits/sched.h used to define both sched_param and > __sched_param with the __sched_priority field, and #define > sched_priority to __sched_priority. I can do that, it's fine. This is actually worse than having struct sched_param defined by sys/types.h, because sched.h is now defining *macro* names that it's not supposed to. It's far more likely that a program will try to define a variable named 'sched_priority' than that it will try to define its own 'struct sched_param'. Can I ask whether you want to keep exposing the internals of pthread_* types to applications? If there's a plan to stop doing that - even a "yeah but it's hard and we have so many other things to do first" intention - then I would recommend leaving sched_param alone for now and just XFAILing the conformance test. On the other hand, if you actively want to keep them exposed and encourage applications to use them, then there does need to be some kind of workaround. zw