Niezupełnie. Standard C nie określa żadnych absolutnych minimalnych limitów dla jednostek tłumaczeniowych, które muszą zostać zaakceptowane. Jako takie, idealnie dokładne sprawdzanie byłoby trywialne napisać, ale całkowicie bezużyteczne w praktyce:
#include <stdio.h>
int main(int argc, char **argv) {
int i;
for (i=1; i<argc; i++)
fprintf(stderr, "`%s`: Translation limit (potentially) exceeded.\n", argv[i]);
return 0;
}
Tak, ten odrzuca wszystko, nie ważne jak błahe. Jest to zgodne z normą. Jak już powiedziałem, w praktyce jest to całkowicie bezużyteczne. Niestety, naprawdę nie można zrobić nic lepszego - gdy zdecydujesz się na przeniesienie do innej implementacji, możesz uruchomić jakiś dziwny limit zasobów, którego nigdy wcześniej nie widziałeś, a więc dowolny napisany kod (aż do " hello world ") może potencjalnie przekroczyć limit zasobów, mimo że jest dozwolony przez dziesiątki, a nawet setki kompilatorów na/dla dużo mniejszych systemów.
Edit:
Dlaczego program "Hello World" nie jest ściśle zgodny
Po pierwsze, warto ponownie podając definicję "ściśle zgodny": „Ściśle Conforming program powinien używać tylko tych, cechy języka i biblioteki określone w niniejszej Normie Międzynarodowej. 2) Nie może generować danych wyjściowych zależnych od jakichkolwiek nieokreślonych, niezdefiniowanych lub zdefiniowanych w ramach implementacji zachowań i nie może przekraczać żadnego minimalnego limitu implementacji. "
W rzeczywistości numer z powodów "Witaj, Świat" nie jest ściśle zgodny. Po pierwsze, jak sugerowano powyżej, minimalne wymagania dotyczące limitów implementacji są całkowicie bez znaczenia - chociaż musi być jakiś program, który spełnia pewne granice, które zostaną zaakceptowane, inny program musi zostać zaakceptowany, nawet jeśli nie spełnia wymagań. nawet zbliżyć się do którejkolwiek z tych granic. Biorąc pod uwagę sposób, w jaki wymóg ten jest określony, można kwestionować (w najlepszym przypadku), czy istnieje coś takiego jak program, który nie przekracza żadnego minimalnego limitu implementacji, ponieważ norma tak naprawdę nie definiuje żadnych minimalnych ograniczeń implementacji.
Po drugie, w fazie 1 tłumaczenia: "Pliki wielobajtowe w fizycznym pliku źródłowym są odwzorowywane, w sposób określony w ramach implementacji, na zestaw znaków źródłowych ..." (§5.1.1.2/1). Od "Hello, World!" (lub dowolny inny wariant) jest dostarczany w pliku źródłowym jako literał łańcuchowy, może być (jest) zmapowany w sposób określony przez implementację do zestawu znaków źródłowych. Implementacja może dowolnie decydować, że (dla przykładu idiotycznego) literały łańcuchowe będą kodowane ROT13, i dopóki ten fakt jest odpowiednio udokumentowany, jest to całkowicie uzasadnione.
Po trzecie, dane wyjściowe są zwykle zapisywane przez stdout. stdout to strumień tekstowy. Zgodnie ze standardem: "Znaki mogą być dodawane, zmieniane lub usuwane na wejściach i wyjściach, aby pasowały do różnych konwencji reprezentujących tekst w środowisku hosta." Tak więc nie musi występować jedna do jednej korespondencji między znakami w strumieniu i w reprezentacji zewnętrznej. " (§7.19.2/2) Jako takie, implementacja może (na przykład) wykonać kompresję Huffmana na wyjściu (w poniedziałek, środę lub piątek).
Mamy więc (co najmniej) trzy różne punkty, w których wynik "Cześć, Świat!" zależy od cech określonych przez implementację - każda z nich uniemożliwiłaby jej dopasowanie definicji ściśle zgodnego programu.
Twój przykład jest fantastyczny. Nigdy nie myślałem o tak prostych wyrażeń wskaźnikowych. Wierzyłem, że każdy taki nieokreślony stan może zostać wykryty w czasie parsetu. – alecov
Twój przykład jest w porządku, nawet jeśli 'p == q' - być może miałeś na myśli' * p = (* q) ++ ', który jest niezdefiniowany jeśli' p == q'? – caf