[PATCH v5 3/8] Cygwin: winsup/doc/posix.xml: SUS V5 POSIX 2024 not implemented new additions

Brian Inglis Brian.Inglis@SystematicSW.ab.ca
Tue Jan 14 23:44:20 GMT 2025


On 2025-01-13 11:01, Brian Inglis wrote:
> On 2025-01-13 05:58, Corinna Vinschen wrote:
>> On Jan 10 17:01, Brian Inglis wrote:
>>> Add unavailable POSIX additions to Not Implemented section,
>>> with mentions of headers and packages where they are expected.
>>>
>>> Signed-off-by: Brian Inglis <Brian.Inglis@SystematicSW.ab.ca>
>>> ---
>>>   winsup/doc/posix.xml | 24 ++++++++++++++++++++++--
>>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/winsup/doc/posix.xml b/winsup/doc/posix.xml
>>> index 17c9ebf6f73f..2e14861802bf 100644
>>> --- a/winsup/doc/posix.xml
>>> +++ b/winsup/doc/posix.xml
>>> @@ -1678,9 +1678,17 @@ ISO/IEC DIS 9945 Information technology
>>>   </sect1>
>>> -<sect1 id="std-notimpl"><title>NOT implemented system interfaces from the 
>>> Single Unix Specification, Volume 7:</title>
>>> +<sect1 id="std-notimpl"><title>NOT implemented system interfaces from the 
>>> Single UNIX® Specification Version 5:</title>
>>>   <screen>
>>> +    CMPLX            (not available in "complex.h" header)
>>> +    CMPLXF            (not available in "complex.h" header)
>>> +    CMPLXL            (not available in "complex.h" header)
>>
>> Erm... did you have a look into newlib/libc/include/complex.h?
> 
> I only looked at build include definition dump from Cygwin gcc 12,
> which does not include this, only:
> 
> . /usr/include/complex.h
> .. /usr/include/sys/cdefs.h
> ... /usr/include/machine/_default_types.h
> .... /usr/include/sys/features.h
> ..... /usr/include/_newlib_version.h
> ... /usr/lib/gcc/x86_64-pc-cygwin/12/include/stddef.h
> 
> That file was updated last July and in August cygwin-devel 3.5.4 should have 
> included it, but that commit is not in that log, nor 3.5.5, or cygwin-3_5- 
> branch, but is under main and in 3.6.0 tars:
> 
> https://cygwin.com/git?p=newlib-cygwin.git;a=commit;f=newlib/libc/include/ 
> complex.h;h=a5ffae14
> 
> $ curl https://mirror.cpsc.ucalgary.ca/mirror/cygwin.com/x86_64/release/cygwin/ 
> cygwin-devel/cygwin-devel-3.5.5-1.tar.xz | tar -xJOf - usr/include/complex.h | 
> grep CMPLX; echo $?
> 1
> 
> $ curl https://mirror.cpsc.ucalgary.ca/mirror/cygwin.com/x86_64/release/cygwin/ 
> cygwin-devel/cygwin-devel-3.6.0-0.278.g376fe1dab177.tar.xz | tar -xJOf - usr/ 
> include/complex.h | grep CMPLX ; echo $?
> #define    CMPLX(x, y)    ((double complex){ x, y })
> #define    CMPLXF(x, y)    ((float complex){ x, y })
> #define    CMPLXL(x, y)    ((long double complex){ x, y })
> #define    CMPLX(x, y)    __builtin_complex((double)(x), (double)(y))
> #define    CMPLXF(x, y)    __builtin_complex((float)(x), (float)(y))
> #define    CMPLXL(x, y)    __builtin_complex((long double)(x), (long double)(y))
> 0
> 
>> Also, don't add the "(not available ..." stuff if the API is supposed to
>> be implemented and exported by newlib/Cygwin.
>>
>>> +    dcgettext_l            (not available in external gettext "libintl" 
>>> library)
>>> +    dcngettext_l        (not available in external gettext "libintl" library)
>>> +    dgettext_l            (not available in external gettext "libintl" library)
>>> +    dngettext_l            (not available in external gettext "libintl" 
>>> library)
>>
>> ...so in case of these libintl functions, it's ok, of course.
>>
>>> +    kill_dependency        (not available in "stdatomic.h" header)
>>
>> This is in /usr/lib/gcc/x86_64-pc-cygwin/12/include/c++/bits/atomic_base.h
> 
> But not in a standard Cygwin gcc 12 build which uses:
> 
> $ grep -A2 kill_ /usr/lib/gcc/x86_64-pc-cygwin/12/include/stdatomic.h
> #define kill_dependency(Y)            \
>    __extension__                    \
>    ({                        \
>      __auto_type __kill_dependency_tmp = (Y);    \
>      __kill_dependency_tmp;            \
>    })
> 
> and I missed checking earlier and qualifies? :^<
> 
> Should I change those comments to "available in" and qualify stdatomic.h with 
> GCC or lib/gcc?

Looking at the end/get/set...ent groups, endhostent and sethostent are 
implemented and gethostent is not implemented - should we keep them separate or 
combine in one section?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry



More information about the Cygwin-patches mailing list