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