Update POSIX compliance guide

Thu Mar 26 19:39:25 UTC 2020

On Thu, Mar 26, 2020 at 12:51 PM Aditya Upadhyay <aadit0402 at gmail.com>
wrote:

> Hi Joel,
>

Ticket for unsupportable methods in the POSIX Guide:

https://devel.rtems.org/ticket/3918#ticket

>
> 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 ;).
>

I don't remember this discussion and beyond the _r methods am drawing a
blank. What did we discuss? :)

> We can also add others sections like what should go into Newlib-cygwin and
> what we need to include in RTEMS or RTEMS-LibBSD.
>

I think this is a topic for the Software Engineering Guide since that's
more focused on developers. I don't know where it should go though.

It is definitely something that is hard to get your head around.

https://devel.rtems.org/ticket/3917#ticket  is there now.

>
> 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/56c18cc3/attachment.html>