<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 26, 2020 at 1:49 AM Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>><br>
>> I went through the implementations in FreeBSD, NetBSD and musl<br>
>> they all require fork().<br>
>> So they can't be used by RTEMS.<br>
><br>
><br>
> Read <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html" rel="noreferrer" target="_blank">https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html</a> and see<br>
> that it even includes an example of how you could implement this using forking<br>
> echo and using pipes to capture the output.<br>
><br>
It's not required though. We can do a clean implementation of it<br>
without fork, and provide some use case with RTEMS shell. This would<br>
be a nice bit of coding work for GSoC beyond porting/fixup. I'd<br>
strongly encourage it.<br></blockquote><div>I have added it to the list and starting to study more about it. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I'm open to ideas on a small string to put in the Compliance spreadsheet to mark<br>
> methods that we will never support. All of the posix_spawn() and this fall into that<br>
> category. This would help avoid this analysis happening again.<br>
><br>
> And once we figure that out, I hope I can figure out the magic in the Python script<br>
> that generates the document from the spreadsheet. :)<br>
><br>
> Gedare.. do you think we should add a section to the POSIX Users Guide on<br>
> Unsupportable Methods? Not full man pages but maybe a subsection per header<br>
> file with unsupportable methods, the list of methods and some rationale?<br>
><br>
Wouldn't hurt. It'll take some doing though, and isn't appropriate as<br>
a GSoC milestone but could be a side-contribution.<br>
<br>
>><br>
>><br>
>> On Wed, Mar 25, 2020 at 11:17 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>> wrote:<br>
>>><br>
>>> Hi Eshan,<br>
>>><br>
>>> We can work with the newlib community. Some things can be done in<br>
>>> newlib that are only for RTEMS, while some things we should share with<br>
>>> others, and still more code may be not useable by RTEMS (e.g., what is<br>
>>> in sys/linux). It is best to try to make common code available, but if<br>
>>> some code has to be specialized for RTEMS differently than how it<br>
>>> works in other systems then we can do that.<br>
>>><br>
>>> Gedare<br>
>>><br>
>>> On Wed, Mar 25, 2020 at 11:06 AM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>>> ><br>
>>> > I will check the musl for a more RTEMS  supported implementation.<br>
>>> > but will newlib change the implementation??<br>
>>> ><br>
>>> > On Wed, Mar 25, 2020 at 8:26 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>>> >><br>
>>> >><br>
>>> >><br>
>>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>>> >>><br>
>>> >>> I have also checked wordexp.h is completely present in newlib (libc/include)<br>
>>> >>> the implementation of the functions wordexp.c and wordfree.c  is in (libc/posix)<br>
>>> >>> But the compliance status shows not supported.<br>
>>> >><br>
>>> >><br>
>>> >> I don't see them in libc.a for the sparc:<br>
>>> >><br>
>>> >> lib_a-wordexp.o:<br>
>>> >><br>
>>> >> lib_a-wordfree.o:<br>
>>> >><br>
>>> >><br>
>>> >> It is not included in RTEMS because the newlib implementation requires multiple<br>
>>> >> processes. It uses fork() and pipes.<br>
>>> >><br>
>>> >> Maybe MUSCL has an implementation that is embedded friendly but the compliance<br>
>>> >> guide is correct.<br>
>>> >><br>
>>> >> --joel<br>
>>> >><br>
>>> >>><br>
>>> >>><br>
>>> >>><br>
>>> >>> On Sat, Mar 21, 2020 at 11:31 PM Joel Sherrill <<a href="mailto:joel@rtems.org" target="_blank">joel@rtems.org</a>> wrote:<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>>> >>>>><br>
>>> >>>>> Hello everyone<br>
>>> >>>>><br>
>>> >>>>> I went through the POSIX Compliance guide and it showed that  wcsncasecmp_l () was not supported in wchar.h<br>
>>> >>>>> But when I checked newlib it had been implemented in libc/string<br>
>>> >>>>> so I think it needs to be updated in the docs.<br>
>>> >>>><br>
>>> >>>><br>
>>> >>>> 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.<br>
>>> >>>><br>
>>> >>>> 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.<br>
>>> >>>><br>
>>> >>>> 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 <a href="http://sourceware.org" rel="noreferrer" target="_blank">sourceware.org</a>. Then checked gdb and it had the same issue. This resulted in also reporting some leftover cleanup from the recent upgrade of <a href="http://sourceware.org" rel="noreferrer" target="_blank">sourceware.org</a>.<br>
>>> >>>>><br>
>>> >>>>><br>
>>> >>>>> Thanks<br>
>>> >>>>> Eshan<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > devel mailing list<br>
>>> > <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
>>> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>