Sub-Tickets selected for POSIX Compilance GSoc Project

[Vaibhav Gupta]

Hello,

I send a patch to add a Test suite for inttypes.h (psxinttypes01.exe) in
testsuites/psxtests, few days ago.
.
It would be great if it can be reviewed.

Thanks
Vaibhav Gupta

On Sat, 23 Mar, 2019, 12:12 PM Vaibhav Gupta <vaibhavgupta40 at gmail.com
wrote:

> For long double and complex methods,
> I compared the given resources:
>
> https://docs.rtems.org/branches/master/posix-compliance/posix-compliance.html
> https://wiki.freebsd.org/Numerics
> .
> Following Function/Features are missing from newlib / RTEMS:
> - CMPLX
> - CMPLXF
> - CMPLXL
> - sincos
> - sincosf
> - sincosl
> - FENV_ACCESS
> - FENV_Contract
> .
> And for FENV_ACCESS, FP_CONTRACT, https://wiki.freebsd.org/Numerics, has
> tagged them for change in compiler. So will they be feasible to implement
> here?
>
> On Sat, Mar 23, 2019 at 11:42 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
> wrote:
>
>> Ticket #2974 - Enable search.h functionality in newlib. :
>> https://devel.rtems.org/ticket/2974
>> .
>> The following declarations are missing from
>> newlib-cygwin/newlib/libc/include/search.h:
>>
>> void   insque(void *, void *);
>> void  *lfind(const void *, const void *, size_t *, size_t, int (*)(const
>> void *const void *));
>> void  *lsearch(const void *, void *, size_t *, size_t, int (*)(const void
>> *, const void *));
>> void   remque(void *);
>>
>> This work can be added to POSIX Compilance for GSoC?
>>
>> On Fri, Mar 22, 2019 at 12:35 AM Joel Sherrill <joel at rtems.org> wrote:
>>
>>>
>>>
>>> On Thu, Mar 21, 2019 at 9:05 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Mar 21, 2019 at 6:10 PM Joel Sherrill <joel at rtems.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu, Mar 21, 2019, 2:43 AM Vaibhav Gupta <vaibhavgupta40 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>> After series of discussions and exploring things, I got Idea about
>>>>>> various things in this project.
>>>>>> I have got Interested in following sub-tickets:
>>>>>> -- #2970 - Add ftw.h to Newlib : https://devel.rtems.org/ticket/2970
>>>>>> -- #2971 - Add fenv.h to Newlib : https://devel.rtems.org/ticket/2971
>>>>>> -- #2972 - Add ndbm.h support : https://devel.rtems.org/ticket/2972
>>>>>> -- #3639 - Add fmtmsg.h to Newlib :
>>>>>> https://devel.rtems.org/ticket/3639
>>>>>> -- #3650 - Add sys/ipc.h to Newlib :
>>>>>> https://devel.rtems.org/ticket/3650
>>>>>>
>>>>>
>>>>> This should be low priority.
>>>>>
>>>>> -- #2973 - Enable getdate() in Newlib :
>>>>>> https://devel.rtems.org/ticket/2973
>>>>>> -- #2974 - Enable search.h functionality in Newlib :
>>>>>> https://devel.rtems.org/ticket/2974
>>>>>> -- Requrement from FACE GPP :
>>>>>>
>>>>>>    - -- math functions:
>>>>>>    - fpclassify()
>>>>>>       - isfinite()
>>>>>>       - isgreater()
>>>>>>       - isgreaterequal()
>>>>>>       - isless()
>>>>>>       - islessequal()
>>>>>>       - islessgreater()
>>>>>>       - isnormal()
>>>>>>       - isunordered()
>>>>>>       - nexttowardf()
>>>>>>       - signbit()
>>>>>>
>>>>>>
>>>>> This is fenv.h and IMO is higher priority for architectures where you
>>>>> are porting existing implementations.
>>>>>
>>>> Yah, so during my SoC time I will start with them first.
>>>> I guess I may find them on FreeBSD, had a little search on net.
>>>> Will get deeper in the topic once the sub-tasks are confirmed,
>>>> as for now I am going through tickets for POSIX Compliance.
>>>>
>>>
>>> +1  Add them to rtems-libbsd
>>>
>>>
>>>>
>>>>>>
>>>>>>    - -- pselect() from <sys/select.h>
>>>>>>    - -- sockatmark() from <sys/socket.h>
>>>>>>
>>>>>> Sebastian.. are these not in the new tcpip stack?
>>>>>
>>>>> And agree with Sebastian on the *at methods.
>>>>>
>>>> That's great. I am ready to work on them.
>>>>
>>>>>
>>>>>
>>>>>>    - -- confstr() from <unistd.h>
>>>>>>
>>>>>>
>>>>>>
>>>>>>    - -- spawn function:
>>>>>>    - posix_spawn()
>>>>>>       - posix_spawn_file_actions_addclose()
>>>>>>       - posix_spawn_file_actions_adddup2()
>>>>>>       - posix_spawn_file_actions_addopen()
>>>>>>       - posix_spawn_file_actions_destroy()
>>>>>>       - posix_spawn_file_actions_init()
>>>>>>       - posix_spawnattr_destroy()
>>>>>>       - posix_spawnattr_getflags()
>>>>>>       - posix_spawnattr_getpgroup()
>>>>>>       - posix_spawnattr_getschedparam()
>>>>>>       - posix_spawnattr_getschedpolicy()
>>>>>>       - posix_spawnattr_getsigdefault()
>>>>>>       - posix_spawnattr_getsigmask()
>>>>>>       - posix_spawnattr_init()
>>>>>>       - posix_spawnattr_setflags()
>>>>>>       - posix_spawnattr_setpgroup()
>>>>>>       - posix_spawnattr_setschedparam()
>>>>>>       - posix_spawnattr_setschedpolicy()
>>>>>>       - posix_spawnattr_setsigdefault()
>>>>>>       - posix_spawnattr_setsigmask()
>>>>>>       - posix_spawnp(
>>>>>>
>>>>>> Spawn is a safer alternative to fork and exec. This requires
>>>>> multi-process support and thus these are not implementable on RTEMS.
>>>>>
>>>> Yah, i had this query in my mind, but then they were also not tagged as
>>>> POSIX_MULTI_PROCESS in FACE Technical Standards 3.0
>>>> and as you said about multi-process functions to be optional, i was not
>>>> able to conclude about them.
>>>> So I will leave it.
>>>>
>>>
>>> Good catch. The FACE ticket for allowing multiple processes to be
>>> optional
>>> missed _POSIX_SPAWN. Luckily it hasn't made a release and I was just
>>> addressing
>>> this earlier this week. So I need to correct the FACE ticket. :)
>>>
>>>>
>>>>> If there is an existing ticket, it needs to state this.
>>>>>
>>>>>
>>>>>
>>>>>> If they all compile into a good GSoC project, I would like to start
>>>>>> writing a draft proposal.
>>>>>>
>>>>>> Thanks
>>>>>> Vaibhav Gupta
>>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190324/b8d2ea56/attachment-0002.html>