On Thu, Mar 26, 2020 at 12:51 PM Aditya Upadhyay <aadit0...@gmail.com> wrote:
> Hi Joel, > Ticket for unsupportable methods in the POSIX Guide: https://devel.rtems.org/ticket/3918#ticket > > 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 ;). > I don't remember this discussion and beyond the _r methods am drawing a blank. What did we discuss? :) > We can also add others sections like what should go into Newlib-cygwin and > what we need to include in RTEMS or RTEMS-LibBSD. > I think this is a topic for the Software Engineering Guide since that's more focused on developers. I don't know where it should go though. It is definitely something that is hard to get your head around. https://devel.rtems.org/ticket/3917#ticket is there now. > > 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
