From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40463 invoked by alias); 18 Apr 2018 18:53:48 -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 40453 invoked by uid 89); 18 Apr 2018 18:53:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=Hx-languages-length:1377 X-HELO: hera.aquilenet.fr Date: Wed, 18 Apr 2018 18:53:00 -0000 From: Samuel Thibault To: Zack Weinberg Cc: Joseph Myers , Florian Weimer , Thomas Schwinge , GNU C Library , bug-hurd@gnu.org, David Michael Subject: Re: Upstreaming the glibc Hurd port Message-ID: <20180418185342.qaeyh7rcink7ygye@var.youpi.perso.aquilenet.fr> Mail-Followup-To: Zack Weinberg , Joseph Myers , Florian Weimer , Thomas Schwinge , GNU C Library , bug-hurd@gnu.org, David Michael References: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-SW-Source: 2018-04/txt/msg00318.txt.bz2 Zack Weinberg, le mer. 18 avril 2018 14:40:29 -0400, a ecrit: > 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'. Sure. glibc just has been #defining sched_priority for a very long time already :) > 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. That's it indeed. Samuel