From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49447 invoked by alias); 24 May 2017 05:42:54 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 49274 invoked by uid 89); 24 May 2017 05:42:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: Yes, score=5.3 required=5.0 tests=AWL,BAYES_20,FOREIGN_BODY,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.2 spammy=nachricht, d-82178, Sinne, puchheim X-HELO: dedi548.your-server.de Received: from dedi548.your-server.de (HELO dedi548.your-server.de) (85.10.215.148) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 05:42:32 +0000 Received: from [88.198.220.132] (helo=sslproxy03.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1dDP45-0006zX-R5; Wed, 24 May 2017 07:42:33 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dDP45-0003uI-8H; Wed, 24 May 2017 07:42:33 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4E2802A0929; Wed, 24 May 2017 07:43:15 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZBKl09GrtxxU; Wed, 24 May 2017 07:43:14 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id E69072A092A; Wed, 24 May 2017 07:43:14 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mXUtwYzEM_MX; Wed, 24 May 2017 07:43:14 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id AA19E2A0929; Wed, 24 May 2017 07:43:14 +0200 (CEST) Subject: Re: [PATCH] Use __BSD_VISIBLE for RTEMS To: Craig Howland , newlib@sourceware.org References: <20170523082353.1793-1-sebastian.huber@embedded-brains.de> <63f3609c-9556-f093-5b0d-98da23faa293@LGSInnovations.com> From: Sebastian Huber Message-ID: <779f4e8d-840a-2887-b432-a8bad9bbc93a@embedded-brains.de> Date: Wed, 24 May 2017 05:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <63f3609c-9556-f093-5b0d-98da23faa293@LGSInnovations.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00354.txt.bz2 On 23/05/17 17:16, Craig Howland wrote: > On 05/23/2017 04:23 AM, Sebastian Huber wrote: >> The Termios header used _POSIX_SOURCE directly to >> determine if a thing should be exposed to the user. This circumvented >> the feature mechanisms of . > Would you please explain why !_POSIX_SOURCE being replaced with=20 > __BSD_VISIBLE rather than, for example, !__POSIX_VISIBLE? A negation of visibility define makes no sense. > That is, you seem to not only be updating to sys/features.h macro=20 > names, but also shifting exactly how the gate is done. (I'm not=20 > saying it is necessarily incorrect, just that the explanation does not=20 > mention the logic change. The two are not logical opposites, so an=20 > implication is that the original gate of POSIX is not really the right=20 > one.)=20 This is an import from FreeBSD. To me this looks like FreeBSD forgot to=20 update the Termios headers to use the visibility defines. https://lists.freebsd.org/pipermail/freebsd-hackers/2017-May/051069.html --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG.