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