Update POSIX compliance guide

[Joel Sherrill]

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.

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?


>
> 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/766ee168/attachment.html>