From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <jwakely@redhat.com>
Received: from us-smtp-delivery-124.mimecast.com
 (us-smtp-delivery-124.mimecast.com [216.205.24.124])
 by sourceware.org (Postfix) with ESMTP id D99233857823
 for <gcc-patches@gcc.gnu.org>; Tue, 27 Oct 2020 10:23:34 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D99233857823
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com
 [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id
 us-mta-317-47tF0Mq6OUy9Cx8VFpqwbQ-1; Tue, 27 Oct 2020 06:23:32 -0400
X-MC-Unique: 47tF0Mq6OUy9Cx8VFpqwbQ-1
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com
 [10.5.11.12])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CD5FB108E1A3;
 Tue, 27 Oct 2020 10:23:31 +0000 (UTC)
Received: from localhost (unknown [10.33.36.3])
 by smtp.corp.redhat.com (Postfix) with ESMTP id 51E9460C07;
 Tue, 27 Oct 2020 10:23:31 +0000 (UTC)
Date: Tue, 27 Oct 2020 10:23:30 +0000
From: Jonathan Wakely <jwakely@redhat.com>
To: Thomas Rodgers <rodgert@appliantology.com>
Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, trodgers@redhat.com
Subject: Re: [PATCH] libstdc++: Add C++2a synchronization support
Message-ID: <20201027102330.GQ503596@redhat.com>
References: <20201023102859.GA1525304@redhat.com>
 <20201026214827.3530995-1-rodgert@appliantology.com>
MIME-Version: 1.0
In-Reply-To: <20201026214827.3530995-1-rodgert@appliantology.com>
X-Clacks-Overhead: GNU Terry Pratchett
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
 DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS,
 TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on
 server2.sourceware.org
X-BeenThere: gcc-patches@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>,
 <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 10:23:36 -0000

On 26/10/20 14:48 -0700, Thomas Rodgers wrote:
>+#include <ext/numeric_traits.h>
>+
>+#if __has_include(<semaphore.h>)
>+#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1
>+#include <semaphore.h>

It occurs to me now that this check probably isn't robust enough. For
any POSIX system it's probably safe to assume that <semaphore.h> means
the POSIX header and so sem_t is available.

But on non-POSIX systems there could be some other, unrelated header
called <semaphore.h> in the include paths that the user is compiling
this header with. It's not inconceivable that the user's own project
or some third party lib could provide a file called semaphore.h, which
wouldn't define sem_t, sem_init etc.

It's OK for now, but we should revisit this and add an autoconf check
for sem_init etc. to check at build time whether we've got POSIX
semaphores available or not.

Please add a "FIXME: replace this with an autoconf check" comment
here.

OK for trunk with that change, thanks.