<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com">eshandhawan51@gmail.com</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"><div dir="ltr"><div><div>I went through the implementations in FreeBSD, NetBSD and musl <br></div>they all require fork().<br></div>So they can't be used by RTEMS.<br></div></blockquote><div><br></div><div>Read <a href="https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html">https://pubs.opengroup.org/onlinepubs/9699919799/functions/wordexp.html</a> and see</div><div>that it even includes an example of how you could implement this using forking </div><div>echo and using pipes to capture the output.</div><div><br></div><div>I'm open to ideas on a small string to put in the Compliance spreadsheet to mark </div><div>methods that we will never support. All of the posix_spawn() and this fall into that </div><div>category. This would help avoid this analysis happening again.</div><div><br></div><div>And once we figure that out, I hope I can figure out the magic in the Python script</div><div>that generates the document from the spreadsheet. :)</div><div><br></div><div>Gedare.. do you think we should add a section to the POSIX Users Guide on </div><div>Unsupportable Methods? Not full man pages but maybe a subsection per header</div><div>file with unsupportable methods, the list of methods and some rationale?</div><div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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>
</blockquote></div></div>