Update POSIX compliance guide

Wed Mar 25 21:02:17 UTC 2020

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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200325/1a6af305/attachment.html>