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