Po pierwsze zgadzam się, że sytuacja kompatybilności kodu w C jest
tragiczna i w żadnym wypadku nie miałem zamiaru grać adwokata
diabła:)

W dniu piątek, 11 sierpnia 2017 22:03:12 UTC+2 użytkownik slawek napisał:
> Tyle że program napisany w 1975 raczej nie będzie z nim zgodny. Nawet
> taki z 1995 (program, biblioteka) nie skompiluje się bezstresowo. Nie
> tylko rozmiar int (bywa że 16 bitów, bywa 64), ale np. wskaźniki far
> i takie tam.
Kwestia rozmiaru inta została zaprotezowana przez stdint.h i te piękności
typu uint8_t czy uint_least64_t, podejrzewam, że komitet uznał to za
lepsze rozwiązanie niż przyjęcie jakiegoś jedynego słusznego rozmiaru.
Jak wyszło tak wyszło, legacy kod który korzysta wprost z jakiejś
konkretnej wielkości inta się sam nie zmodyfikował.

> Ciekawostką jest że Turbo C nie obsługuje przecinka, tj. nie da się
> napisać x = ( a = 1, b = 2); itp. Czyli znowu problemy z
> przenośnością i z implementacją standardu.
DOSowe kompilatory były tragiczne pod tym względem - wspomniane przez
Ciebie bliskie i dalekie wskaźniki i bardzo średnia implementacja
standardu. Dziękuję za ciekawostkę, bo nie widziałem Turbo C od
"dość" dawna:)

>Nawet dość niedawno musiałem żonglować opcją std w GCC. O
>(domyślnie) nie działającym printf w MSVC chyba też wiesz.
Dość niedawno musiałem żonglować opcją std przy portowaniu
pewnej małej biblioteki pythonowej na OS X, bo okazało się,
że kawałek kodu w C był traktowany przez clanga jako literalne
C90 i odmawiał kompilacji czegoś w stylu
void f(int n) { int array[n]; ........ }

slawek:
>Akurat MSVC miał awersję do VLA. Tyle że od zawsze, czyli jeszcze
>przed C89, bez trudu da się zrobić tablice dynamiczne bez VLA. Tylko
>trzeba umieć programować w C.
Pewnie, że się da, ale jeżeli mam do wyboru użyć wbudowanej funkcji
języka albo wymyślać koło na nowo, to użyję wbudowanej funkcji języka
pod warunkiem, że 1) robi to, czego potrzebuję, 2) na tyle szybko,
na ile potrzebuję.