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 <vaibhavgupt...@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 <vaibhavgupt...@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 <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
