strdup visibility

strdup visibility

[Marco Atzeri]

Hy Guys,

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?

Regards
Marco

Re: strdup visibility

[Yaakov Selkowitz]

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?

-- 
Yaakov

Re: strdup visibility

[marco atzeri]

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?
>
> --
> Yaakov

I saw several source code expecting to access "strdup"
thelast one was Graphviz.

The fast solution, for me, is just to drop a
     #define _GNU_SOURCE 1
on config.h between cygconf and cygmake

Regards
Marco

Re: strdup visibility

[Yaakov Selkowitz]

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