🚀 go-pugleaf

> > Osobiście nie mam problemu z określeniem "POSIX subset".
> Super. To wiele wyjaśnia.

Twórcy tego standardu też nie mają, patrz niżej.

> > Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset"
> A jeśli sa z nim niezgodne, tak fundamentalnie?

To nie zrobisz jednolinijkowej "abstrakcji". Plączesz się w argumentach.

> Nie. Bo to nie działa w tą stronę. Musisz mieć pełny POSIX aby nazywać 
> to "POSIX".

I tu znowu (a raczej wciąż) się mylisz.
Praktyka stosowania podzbiorów (czegokolwiek) jest tak powszechna, zwłaszcza w embedded, że branża nawet znalazła sobie seksowne określenie na to: profil. Różne rzeczy definiuje się dla wielu "profili", właśnie po to, żeby zaadresować różnice w zakresie wspieranej funkcjonalności.
I tak POSIX został podzielony na profile, z czego PSE51 jest najprostszym, zakładającym istnienie jednego, ale być może wielowątkowego procesu, bez systemu plików. To jest opisane w POSIX 1003.13-2008, który jest płatny, ale ślad tego znalazłem tutaj:

https://www.opengroup.org/testing/testsuites/POSIXProfiles.htm

Wizualizacja jest w slajdzie 17 tutaj:

https://www.opengroup.org/austin/docs/austin_279.pdf

Czyli PSE51 to jest profil POSIX stworzony właśnie po to, żeby odzwierciedlić istniejącą praktykę w postaci prostych RTOSików na mikrokontrolery. Jeżeli nadal uważasz, że POSIX nie nadaje się do embedded, bo tam nie ma np. systemu plików, to "you are not even wrong".
Wracając, PSE51 pozwala systemom takim jak FreeRTOS mieć API POSIX. No, chyba że autorzy koniecznie nie chcą. Ale jest kilka systemów, których autorzy chcieli:

https://unix.stackexchange.com/questions/431999/is-there-an-open-source-posix-pse51-compliant-rtos

> POSIX bez pipes to nie POSIX.
> Możesz sobie użyć tego "subset". To dalej nie POSIX.

Zamknijmy ten rozdział już. Masz wystarczająco dużo materiałów.

> >> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior. 
> > Czyli tego określenia też nie rozumiesz. Może podaj przykład.
> Proszę: 
> 
> Mam jedną rurę. Jedne deskryptor do zapisu i jeden do odczytu. 
> Zrób dwa wątki piszące do tego samego deskryptora do zapisu. 
> Określ jakie dane będą lądować po drugiej stronie.

Jeżeli to jest UB, to mogę określić dowolnie. I zweryfikować to, co założyłem. Albo powiedzieć, że tej funkcjonalności w ogóle nie ma. I jej nie weryfikować, bo nie ma po co.
Podobnie jak np. z wyjechaniem poza tablicę w C++.

> 2: Zwołaj ::read i loscią dancyh większą niż SSIZE_MAX (dozwolone).

To samo.

> A ci co zaczeli na januszowym Linuxie?

Oni mogą przenieść swoje programy na inne systemy.

> > A gdyby tak zaczęli, od początku, zgodnie ze standardami?
> To by nigdy nie wystarowali.

Sam pisałeś, że każdy ma swoje własne doświadczenia.

> Ale oni nie są to tego stopnia głupi żeby nie mieć abstrakcji na to 
> FreeTROS. Naprawdę, ludzie nie są aż tak głupi.

I tu też się mylisz... Niestety.

> > Również. https://www.integrasources.com/blog/windows-ce-end-of-life-medical-devices/
> Ale pytam o Windowsy współczesne.

A jak pisałem wcześniej o współczesnych Macach to się rzucałeś że kiedyś komuś coś przestało działać. No i?
Ocena ryzyka jest częścią decyzji biznesowej. Jak komuś pasuje robić projekt embedded z Windowsem (czy z czymkolwiek innym, co nie spełnia żadnych standardów) w środku, to jego problem.

> > Za to ludzie, którzy użyli Windowsa CE, mają teraz powody, żeby się przenosić gdzie indziej.
> Przez wiele lat nie mieli tych powodów.

Więc skoro przez wiele lat nie trzeba się nigdzie przesiadać, to o czym rozmawiamy? Najwyraźniej o problemie, którego nie ma.

-- 
Maciej Sobczak * http://www.inspirel.com