Я интересно, если C сниппет ниже, в котором определение f
не удается повторить, что f
имеет static
связи, является правильным:Согласованность связи между декларацией и определением
static int f(int);
int f(int x) { return x; }
Clang не выделяет какой-либо предупреждая об этом. Я прочитал раздел 6.7.1 стандарта C11, не найдя ответа на мой вопрос.
Можно представить себе больше вопросов в том же духе, например, t1.c и t2.c ниже, и было бы неплохо, если бы ответ был достаточно общим, чтобы применить к некоторым из них, но я на самом деле обеспокоенный первым примером выше.
~ $ cat t1.c
static int f(int);
int f(int);
int f(int x) { return x; }
~ $ clang -c -std=c99 -pedantic t1.c
~ $ nm t1.o
warning: /Applications/Xcode.app/…/bin/nm: no name list
~ $ cat t2.c
int f(int);
static int f(int);
int f(int x) { return x; }
~ $ clang -c -std=c99 -pedantic t2.c
t2.c:3:12: error: static declaration of 'f' follows non-static declaration
static int f(int);
^
t2.c:1:5: note: previous declaration is here
int f(int);
^
1 error generated.
Я не понимаю, почему второй фрагмент требует диагностики. В противоположность тому, что цитирует @BlueMoon, кажется, что это «единственный» - это UB. –
@JensGustedt: Спасибо, мне было интересно, как UB, упомянутый в ответе Blue Moon, должен произойти вообще, если это было нарушение ограничений, и это ответ. Я правильно понимаю, что, как правило, отказ от компиляции на UB (в заявлении) означает, что компилятор должен иметь возможность определить, что данный код доступен, но это не применимо здесь, потому что мы имеем дело с (file-scope) объявления? – mafso
Да, вот это код, который не выполнен, поэтому достижимость не имеет большого смысла :) UB здесь означает, что вся программа имеет UB с самого начала. Вероятно, в основном потому, что ссылка на идентификаторы, возможно, пошла не так. Тем не менее, учитывая, что, поскольку UB является немного хромым, это легко обнаружить во время компиляции, так что, по-моему, нарушение ограничений будет в порядке. –