> To oznacza że POSIX nie jest dobrą abstrakcją na OS b wymaga tego
> wszystkiego aby być POSIXem. Inaczej nie jest POSIXem.

Osobiście nie mam problemu z określeniem "POSIX subset".
Więc chcę, żeby januszowe RTOSiki implementowały "POSIX subset" - w takim zakresie, w
jakim w ogóle coś implementują.

> Każda konfiguracja, inna niż *wszystko*, nie jest już POSIXem.

I w konsekwencji program, który nie korzysta ze *wszystkiego* nie jest programem
POSIXowym?
A program, który nie korzysta ze *wszystkiego* z biblioteki standardowej C++ nie jest
programem w C++?

Ja ze słowem "subset" nie mam problemu, zwłaszcza w embedded.
Natomiast mam problem z niekompatybilnością bez wartości dodanej.

> > I niepotrzebnych rzeczy nie ma, zwłaszcza w systemach embedded.
> To po co tam wciskać POSIXa skoro używa się 5% jego api?

Dokładnie po to, co opisano w pierwszym zdaniu na wikipedii, któro nadal uporczywie
ignorujesz. Po to, żeby zapewnić "compatibility between operating systems".

> > Sam sobie zaprzeczasz. "W jakiejś implementacji"?
> Jakiejś. Widzisz, POSIX ma bardzo dużo undefined behavior.

Czyli tego określenia też nie rozumiesz. Może podaj przykład.

> > A jeśli mam formalnie zweryfikowaną implementację
> Wątplię, aby ktoś formalnie weryfikował POSIXa. Z uwagi na UB. Ale może
> sie mylę, znasz przykład?

Najpierw podaj przykład tego UB. Wtedy będzie wiadomo, co trzeba z tym UB zrobić,
żeby przestało być UB - a w dalszej kolejności jak to zweryfikować.

Ciekawe, że UB nie przeszkadza w osiągnięciu celu, którym jest przenośność. Tak jest
też w C albo w C++.

> Jeśli z ::read może wylecieć 20 róznych stanów to nie jest to dobre API.

To, że może, to nie znaczy, że musi (patrz subset). A jeśli w ogóle nie ma read?
Mówimy o embedded.

> Który to SafeRTOS jest bez wątpienia POSIX like. I w dodatku bazujący na
> API FreeRTOS :D Ależ to życie jest złośliwe.

Jest bazujący na API FreeRTOS z takiego powodu, że ktoś chce zarobić na tych
wszystkich ludziach, którzy zaczęli robić projekty na januszowym FreeRTOS i dotarli z
tymi projektami do punktu, w którym ktoś ich pyta o jakość (ale jak to?) a *nie są w
stanie przenieść tych projektów na inny system, bo są więźniami tego nieprzenośnego
API. Wtedy płacą cenę (w formie licencji za SafeRTOS) za januszostwo i olewanie
standardów.
A gdyby tak zaczęli, od początku, zgodnie ze standardami? To nie byliby skazani na tą
jedyną ofertę "nie do odrzucenia". To się nazywa ten vendor-lockin, o którym pisałeś.
Tutaj, oczywiście, wykażasz się odpornością na to zjawisko, bo napisałeś sobie
wrapper. Ja się wykażę odpornością, bo piszę pod standard. Możemy się pogodzić w tym,
że żaden z nas nie musi płacić za SafeRTOS.

> > Od kiedy API utrudnia weryfikację? W jaki sposób?
> W taki sposób:
>
> switch ( fooResult )
> {
> case Error:
> case OtherError:
> case UlikelyError:
> case SomethingBroken:
> case DoItAgainPlease:
> case MabyeLater:
> case OKButNotQuite:
> case Almost:
> case NeedRest:
> case Interrupt!:
> }

Dalej nie rozumiesz. Nikt nie każdy RTOSowi zwracać wszystkich możliwych błędów.
Standard mówi, jakie błędy można zwrócić, a nie jakie trzeba. Więc jeśli jakiś RTOS
ma tylko 3 stany w swojej implementacji, to te trzy stany mogą się nazywać tak jak w
POSIX a nie inaczej "bo tak". Słowo klucz: "subset".

> A program napisany w Qt jest jeszcze bardziej przenośny od tego w POSIXie.

Albo i nie. Systemów POSIXowych jest chyba więcej, niż tych wspieranych przez Qt.
W szczególności, wspomniany przeze mnie TI-RTOS (od Texasa) ma interfejs POSIX a
raczej Qt tam nie zadziała.

> Na przykład obok jest CreateMutex biorący 3 parametry.

pthread_mutex_init ma argument pthread_mutexattr_t, w dodatku przez wskaźnik, więc
możliwości funkcjonalne tego są właściwie nieograniczone. Może być NULL dla
zachowania domyślnego. Nie ma problemu, żeby w tej jednej funkcji zmieścić zarówno
bezargumentową inicjalizację, jak i specjalne ficzery.
Właśnie o to chodzi w standardach.

> > Do przenośności wystarczyłby POSIX
>
> Nie chcesz takiej przenośności. POSIX to gówno. Pod wieloma względami to
> zamrożone workaroundy z lat 70tych.

Nie napisałeś niczego, żeby to potwierdzić.

> >, gdyby twórcy januszowych RTOSików
>
> A twórcy januszowych Windowsów?

Również. https://www.integrasources.com/blog/windows-ce-end-o
f-life-medical-devices/

Tak to jest jak się uwierzy komuś, kto olewa standardy.

> > Dlatego chciałbym mieć *jedną* implementację mojej klasy MyMutex. A nie kilka
różnych.
> Nie ma takiej potrzeby. I tak masz dwie co najmniej. Przecięz masz
> jeszcze mocka do testów.

Mocka muteksa? A po co? Normalny muteks po prostu działa, bo... no właśnie, bo jest
standardowy.

> > Jeśli trzeba puścić unit testy, to Cygwin jest do tego jak najbardziej
wystarczający.
> Ano właśnie, znalazłeś adapter do systemu operacyjnego. Bardzo milutko.
> Nie sprzedasz jednak aplikcji napisanej na cygwinie,

Znowu manipulujesz. Aplikacja jest napisana na jakiś system embedded. A konkretnie na
POSIXowy system. Sprzedam ją bez problemu. To, że być może testy nieformalne (!) były
puszczane na Cygwinie, nie ma żadnego znaczenia.

> pozerkaj jak bardzo
> wieli ból dupy mają twórcy cygwina z powodu niekompatybilnosci POSIXA z
> WinApi

Nie jest to problemem dla *subsetu*, którego używam w projektach embedded.

> POSIX to jest taki standard z przypadku. Microsoft
> nie ma śadu powodu aby go używac.

Za to ludzie, którzy użyli Windowsa CE, mają teraz powody, żeby się przenosić gdzie
indziej.

> > Już rozumiem. Ty piszesz o tym, jak jest a ja o tym, jak powinno być
> Idealista.

Inżynier. :-)

> Tupanie nogą że świat nie jest POSIXowy i na siłe uzależnianei się od
> tego kipeskiego API nie jest specjalnie profesjonalne.

Specjalnie nie jest, jest po prostu racjonalne, o ile w ogóle trzeba na jakimś API
polegać.
Natomiast specjalnie nieprofesjonalne jest na siłę nieprzestrzeganie standardów, "bo
nie".

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