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 <j...@rtems.org> wrote: > > > On Thu, Mar 21, 2019 at 9:05 AM Vaibhav Gupta <vaibhavgupt...@gmail.com> > wrote: > >> >> >> On Thu, Mar 21, 2019 at 6:10 PM Joel Sherrill <j...@rtems.org> wrote: >> >>> >>> >>> On Thu, Mar 21, 2019, 2:43 AM Vaibhav Gupta <vaibhavgupt...@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 >>>> >>>
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
