Sub-Tickets selected for POSIX Compilance GSoc Project

Vaibhav Gupta vaibhavgupta40 at gmail.com
Sat Mar 23 06:42:12 UTC 2019


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/20190323/66018a41/attachment-0002.html>


More information about the devel mailing list