From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-44.mimecast.com (us-smtp-delivery-44.mimecast.com [207.211.30.44]) by sourceware.org (Postfix) with ESMTP id B1D8B385800C for ; Fri, 19 Feb 2021 03:03:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B1D8B385800C 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-321-SLyhvVfYOxCh8zOsjPNA7w-1; Thu, 18 Feb 2021 22:03:37 -0500 X-MC-Unique: SLyhvVfYOxCh8zOsjPNA7w-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4582AC293 for ; Fri, 19 Feb 2021 03:03:36 +0000 (UTC) Received: from yselkowitz.remote.redhat.com (ovpn-112-7.rdu2.redhat.com [10.10.112.7]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C61F410016DB for ; Fri, 19 Feb 2021 03:03:35 +0000 (UTC) Message-ID: <7399b26b798ed3dabfa84f0308783c5e8cf4a823.camel@cygwin.com> Subject: Re: strdup visibility From: Yaakov Selkowitz To: cygwin-developers@cygwin.com Date: Thu, 18 Feb 2021 22:03:34 -0500 In-Reply-To: References: <6d8bd601-10ef-5ae1-551d-0d9ea62ee49e@gmail.com> <29869ada38d29ae1d8eccdac5935a67daf7b035d.camel@cygwin.com> User-Agent: Evolution 3.38.3 (3.38.3-1.fc33) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_NONE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 03:03:41 -0000 On Mon, 2021-02-08 at 13:36 +0100, marco atzeri wrote: > On Mon, Feb 8, 2021 at 7:57 AM Yaakov Selkowitz via Cygwin-developers wro= te: > >=20 > > On Mon, 2021-02-08 at 04:04 +0100, Marco Atzeri via Cygwin-developers > > wrote: > > > currently we have in=C2=A0 /usr/include/string.h > > >=20 > > > #if __MISC_VISIBLE || __POSIX_VISIBLE >=3D 200809 || __XSI_VISIBLE >= =3D 4 > > > char=C2=A0=C2=A0=C2=A0 *strdup (const char *) __malloc_like __result_= use_check; > > > #endif > > >=20 > > >=20 > > > but the function was moved to POSIX base some time ago > > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/strdup.htm= l > > >=20 > > > should the conditional dropped ? Or I misunderstand it? > >=20 > > Anything that is an extension in the ANSI C headers is conditionalized.= =C2=A0 > > Those > > conditions match the progressive standardization of this function and i= t's > > eventual inclusion in POSIX-1.2008. > >=20 > > Have you run into a real-world issue with these conditions? >=20 > I saw several source code expecting to access "strdup" > thelast one was Graphviz. Technically, our FTMs are supposed to match glibc, so this shouldn't happen= in C code unless the code tries to use different CFLAGS for Linux. However, where you might see this is in C++, because g++ defined _GNU_SOURCE unconditionally for Linux targets, which means FTMs are practically ignored thereby, where on Cygwin they still work as designed. I've seen lots of ca= ses of e.g. -std=3Dc++* (which implies strict ANSI absent any FTMs) when -std= =3Dgnu++ should have been used instead, because nobody notices the difference on Lin= ux for that reason. Fixing this in g++&glibc, which would force software to finally do the right thing, has long been on my wish-to-do list. That being said, unless the code has changed greatly since my last build, o= r I just hadn't built the package in a very long time, there should already be patches or workarounds for many of these in my existing source packages. > The fast solution, for me, is just to drop a > =C2=A0=C2=A0=C2=A0=C2=A0 #define _GNU_SOURCE 1 > on config.h between cygconf and cygmake That is a sledgehammer approach, but is essentially what is happening on Linux. However, the "proper" fix is to either find and fix e.g. -std=3Dc++= * flags, and/or to add the necessary _*_SOURCE definitions to the beginning o= f the individual source files which need them. --=20 Yaakov