Update POSIX compliance guide

[Gedare Bloom]

On Wed, Mar 25, 2020 at 1:21 PM Joel Sherrill <joel at rtems.org> wrote:
>
>
>
> On Wed, Mar 25, 2020 at 12:59 PM Eshan Dhawan <eshandhawan51 at 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'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 <gedare at 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 <eshandhawan51 at 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 <joel at rtems.org> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Mar 22, 2020 at 2:00 PM Eshan Dhawan <eshandhawan51 at 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 <joel at rtems.org> wrote:
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Sat, Mar 21, 2020, 8:47 AM Eshan Dhawan <eshandhawan51 at 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 at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/devel