Update POSIX compliance guide

Thu Mar 26 17:51:39 UTC 2020

Hi Joel,

Can we also include or make a separate section for those functions that
needs reentrant version of implementation. When I was GSoC student, I had
struggled a lot making methods reentrant as It was challenging ;). We can
also add others sections like what should go into Newlib-cygwin and what we
need to include in RTEMS or RTEMS-LibBSD.

Thanks,
Aditya Upadhyay

On Thu, 26 Mar 2020, 02:32 Joel Sherrill, <joel at rtems.org> wrote:

>
>
> On Wed, Mar 25, 2020 at 3:43 PM Eshan Dhawan <eshandhawan51 at gmail.com>
> wrote:
>
>>
>>
>> On Thu, Mar 26, 2020 at 1:49 AM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> 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 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 <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
>>>
>> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200326/a17980f3/attachment-0001.html>