2015-12-19 18 views
6

Czytam dokumentację gcc wyprzedzającym, czytam następujące zdanie (here):koniec linii (dokumentacja GNU)

If the last line of any input file lacks an end-of-line marker, the end of the file is considered to implicitly supply one. The C standard says that this condition provokes undefined behavior, so GCC will emit a warning message.

Staram się produkować ostrzeżenia wykonując:

> echo -n "int main(void) {return 0;}" > test.c 
> gcc -Wall -Wextra -Werror test.c 

Ale nie prob, to kompiluje. Rozumiem znacznik końca linii jako znak nowej linii, ale wydaje się, że jest cokolwiek innego.

Jak mogę wygenerować ostrzeżenie?

+3

'gcc -W'. Dlaczego miałbyś kiedykolwiek * uruchamiać GCC bez ostrzeżeń ... –

+0

Prawdopodobnie nikt nie dba o tę sytuację. – bolov

+0

@KerrekSB to prawda, ale użycie '-W' lub' -Wall' na jego przykładzie nadal nie daje udokumentowanego ostrzeżenia, które opisuje. Przynajmniej nie w wersji 'gcc' 4.7.2. – lurker

Odpowiedz

5

Wygląda na to, że został usunięty z gcc.

Zobacz to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14331#c19

2007-05-31

PR preprocessor/14331 
    * lex.c (_cpp_get_fresh_line): Don't warn if no newline at EOF. 
+2

Pierwotnie ostrzeżenie miało być opcjonalne. Ostateczna łata usuwa go bezwarunkowo. Ponieważ zachowanie jest niezdefiniowane, wolałbym mieć opcję włączenia ostrzeżenia. –

+0

Wciąż (GCC 5.3.0) otrzymujesz ostrzeżenie (można zamienić na błąd z '-Werror') dla:' min.c: 1: 29: warning: backslash-newline na końcu pliku' dla pliku zakończonego ukośnikiem odwrotnym Nowa linia. Jeśli masz odwrotny ukośnik bez nowej linii, otrzymasz 'min.c: 1: 1: error: bezpańskie '\' w programie' (bezwarunkowo błąd). Jeśli na końcu masz ukośnik odwrotny-nowa-linia-nowa, nie ma problemu (brak błędu lub przyczyna podania). –

+0

Standard C mówi w §5.1.1.2 Fazy tłumaczenia, ¶2 _Każdy przypadek znaku ukośnika odwrotnego ('\\') zaraz po nim znak nowej linii jest usuwany, łączenie fizycznych linii źródłowych w celu utworzenia logicznych linii źródłowych. Tylko ostatni odwrotny ukośnik na dowolnej fizycznej linii źródłowej może być częścią takiego splotu. Plik źródłowy, który nie jest pusty, kończy się znakiem nowej linii, który nie powinien być bezpośrednio poprzedzany znakiem ukośnika przed takim splicingiem. –

1

C11 (N1570), §5.1.1.2, stany:

A source file that is not empty shall end in a new-line character, which shall not be immediately preceded by a backslash character before any such splicing takes place.

Więc nie ma nowej linii na pliku jest niezgodny z powyższym "przymus".

clang ma ostrzegać o tym:

$ printf "int main(void) {return 0;}" > test.c 
$ clang -Weverything test.c 
test.c:1:27: warning: no newline at end of file [-Wnewline-eof] 
int main(void) {return 0;} 
         ^
1 warning generated. 

Ale ograniczenie naruszenie jest undefined behaviour.

C11 (N1570), §4, stany:

If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint or runtime constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’.

Więc gcc Pozwoliłem sobie wykupić ostrzeżenia (jak zauważył @nnn) jak gcc jest nie wymaga wydać jakikolwiek diagnostyka dla niezdefiniowanych zachowań.