🚀 go-pugleaf

> 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-of-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