Hi Joel, Can we also include or make a separate section for those functions that needs reentrant version of implementation. When I was GSoC student, I had struggled a lot making methods reentrant as It was challenging ;). We can also add others sections like what should go into Newlib-cygwin and what we need to include in RTEMS or RTEMS-LibBSD.
Thanks, Aditya Upadhyay On Thu, 26 Mar 2020, 02:32 Joel Sherrill, <j...@rtems.org> wrote: > > > On Wed, Mar 25, 2020 at 3:43 PM Eshan Dhawan <eshandhawa...@gmail.com> > wrote: > >> >> >> On Thu, Mar 26, 2020 at 1:49 AM Gedare Bloom <ged...@rtems.org> wrote: >> >>> On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill <j...@rtems.org> wrote: >>> > >>> > >>> > >>> > On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan <eshandhawa...@gmail.com> >>> wrote: >>> >> >>> >> I went through the implementations in FreeBSD, NetBSD and musl >>> >> they all require fork(). >>> >> So they can't be used by RTEMS. >>> > >>> > >>> > Read >>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html >>> and see >>> > that it even includes an example of how you could implement this using >>> forking >>> > echo and using pipes to capture the output. >>> > >>> It's not required though. We can do a clean implementation of it >>> without fork, and provide some use case with RTEMS shell. This would >>> be a nice bit of coding work for GSoC beyond porting/fixup. I'd >>> strongly encourage it. >>> >> I have added it to the list and starting to study more about it. >> > > > OK. The POSIX description sounds brutal but .... > > Takes a library that can do wildcard and environment variable expansion as > a minimum. > > >> >>> > I'm open to ideas on a small string to put in the Compliance >>> spreadsheet to mark >>> > methods that we will never support. All of the posix_spawn() and this >>> fall into that >>> > category. This would help avoid this analysis happening again. >>> > >>> > And once we figure that out, I hope I can figure out the magic in the >>> Python script >>> > that generates the document from the spreadsheet. :) >>> > >>> > Gedare.. do you think we should add a section to the POSIX Users Guide >>> on >>> > Unsupportable Methods? Not full man pages but maybe a subsection per >>> header >>> > file with unsupportable methods, the list of methods and some >>> rationale? >>> > >>> Wouldn't hurt. It'll take some doing though, and isn't appropriate as >>> a GSoC milestone but could be a side-contribution. >>> >> > I may go ahead and add a chapter so at least it is easier to add sections. > > >> >>> >> >>> >> >>> >> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom <ged...@rtems.org> >>> wrote: >>> >>> >>> >>> Hi Eshan, >>> >>> >>> >>> We can work with the newlib community. Some things can be done in >>> >>> newlib that are only for RTEMS, while some things we should share >>> with >>> >>> others, and still more code may be not useable by RTEMS (e.g., what >>> is >>> >>> in sys/linux). It is best to try to make common code available, but >>> if >>> >>> some code has to be specialized for RTEMS differently than how it >>> >>> works in other systems then we can do that. >>> >>> >>> >>> Gedare >>> >>> >>> >>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan < >>> eshandhawa...@gmail.com> wrote: >>> >>> > >>> >>> > I will check the musl for a more RTEMS supported implementation. >>> >>> > but will newlib change the implementation?? >>> >>> > >>> >>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill <j...@rtems.org> >>> wrote: >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan < >>> eshandhawa...@gmail.com> wrote: >>> >>> >>> >>> >>> >>> I have also checked wordexp.h is completely present in newlib >>> (libc/include) >>> >>> >>> the implementation of the functions wordexp.c and wordfree.c is >>> in (libc/posix) >>> >>> >>> But the compliance status shows not supported. >>> >>> >> >>> >>> >> >>> >>> >> I don't see them in libc.a for the sparc: >>> >>> >> >>> >>> >> lib_a-wordexp.o: >>> >>> >> >>> >>> >> lib_a-wordfree.o: >>> >>> >> >>> >>> >> >>> >>> >> It is not included in RTEMS because the newlib implementation >>> requires multiple >>> >>> >> processes. It uses fork() and pipes. >>> >>> >> >>> >>> >> Maybe MUSCL has an implementation that is embedded friendly but >>> the compliance >>> >>> >> guide is correct. >>> >>> >> >>> >>> >> --joel >>> >>> >> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill <j...@rtems.org> >>> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan < >>> eshandhawa...@gmail.com> wrote: >>> >>> >>>>> >>> >>> >>>>> Hello everyone >>> >>> >>>>> >>> >>> >>>>> I went through the POSIX Compliance guide and it showed that >>> wcsncasecmp_l () was not supported in wchar.h >>> >>> >>>>> But when I checked newlib it had been implemented in >>> libc/string >>> >>> >>>>> so I think it needs to be updated in the docs. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for spotting this. I did a spot check and think there >>> were a few more wc* methods that were not in the spreadsheet. I am going to >>> post a patch in a bit. Please check it. >>> >>> >>>> >>> >>> >>>> Obviously, this is a csv file maintained externally in a >>> spreadsheet. If you put it in a spreadsheet, you can turn on data filtering >>> based on the top row. Then you can do "queries" to do things like filter >>> down to what's in a single header file. Or what's required in one standard >>> but not in another. >>> >>> >>>> >>> >>> >>>> FWIW this turned into a bit of a rat hole. I tried to double >>> check the newlib git repo and the link on their website is wrong after the >>> upgrade of sourceware.org. Then checked gdb and it had the same issue. >>> This resulted in also reporting some leftover cleanup from the recent >>> upgrade of sourceware.org. >>> >>> >>>>> >>> >>> >>>>> >>> >>> >>>>> Thanks >>> >>> >>>>> Eshan >>> >>> > >>> >>> > _______________________________________________ >>> >>> > devel mailing list >>> >>> > devel@rtems.org >>> >>> > http://lists.rtems.org/mailman/listinfo/devel >>> >> _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
