public inbox for cygwin-developers@cygwin.com
 help / color / mirror / Atom feed
From: Yaakov Selkowitz <yselkowitz@cygwin.com>
To: cygwin-developers@cygwin.com
Subject: Re: strdup visibility
Date: Thu, 18 Feb 2021 22:03:34 -0500	[thread overview]
Message-ID: <7399b26b798ed3dabfa84f0308783c5e8cf4a823.camel@cygwin.com> (raw)
In-Reply-To: <CAB8Xom8KBYXLVzcmdF37xqw=gEQqM3-fiPXEQ3mGo23AiJyydg@mail.gmail.com>

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 wrote:
> > 
> > On Mon, 2021-02-08 at 04:04 +0100, Marco Atzeri via Cygwin-developers
> > wrote:
> > > currently we have in  /usr/include/string.h
> > > 
> > > #if __MISC_VISIBLE || __POSIX_VISIBLE >= 200809 || __XSI_VISIBLE >= 4
> > > char    *strdup (const char *) __malloc_like __result_use_check;
> > > #endif
> > > 
> > > 
> > > but the function was moved to POSIX base some time ago
> > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/strdup.html
> > > 
> > > should the conditional dropped ? Or I misunderstand it?
> > 
> > Anything that is an extension in the ANSI C headers is conditionalized. 
> > Those
> > conditions match the progressive standardization of this function and it's
> > eventual inclusion in POSIX-1.2008.
> > 
> > Have you run into a real-world issue with these conditions?
> 
> 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 cases
of e.g. -std=c++* (which implies strict ANSI absent any FTMs) when -std=gnu++
should have been used instead, because nobody notices the difference on Linux
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, or 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
>      #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=c++*
flags, and/or to add the necessary _*_SOURCE definitions to the beginning of
the individual source files which need them.

-- 
Yaakov


      reply	other threads:[~2021-02-19  3:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-08  3:04 Marco Atzeri
2021-02-08  6:21 ` Yaakov Selkowitz
2021-02-08 12:36   ` marco atzeri
2021-02-19  3:03     ` Yaakov Selkowitz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7399b26b798ed3dabfa84f0308783c5e8cf4a823.camel@cygwin.com \
    --to=yselkowitz@cygwin.com \
    --cc=cygwin-developers@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).