Чому відтікання з кінця недійсної функції без повернення значення не створює помилки компілятора?

З тих пір, як я багато років тому зрозумів, що це не створює помилок за замовчуванням (принаймні в GCC), я завжди цікавився чому?

Я розумію, що ви можете видавати прапори компілятора для створення попередження, але чи не завжди це має бути помилка? Чому має значення недійсна функція, що не повертає значення, що має значення?

Приклад, як вимагають у коментарях:

#include <stdio.h>
int stringSize()
{
}

int main()
{
    char cstring[5];
    printf( "the last char is: %c\n", cstring[stringSize()-1] ); 
    return 0;
}

... компілює.

Стандарти C99 і C ++ не вимагають функцій для повернення значення. Відсутній оператор повернення у функції, що повертає значення, буде визначений (для повернення 0) лише у mainфункції.

Обґрунтування включає в себе те, що перевірити, чи повертає кожний шлях коду значення, досить складно, і повернення значення може бути встановлено за допомогою вбудованого асемблера чи інших хитромудрих методів.

З C ++ 11 чернетки:

§ 6.6.3 / 2

Відтікання від кінця функції [...] призводить до невизначеної поведінки у функції, що повертає значення.

§ 3.6.1 / 5

Якщо контроль доходить до кінця, mainне стикаючись із return твердженням, ефект буде виконати

return 0;

Зауважимо, що поведінка, описана в C ++ 6.6.3 / 2, не однакова в C.

gcc надішле вам попередження, якщо ви будете називати це параметром -Wreturn-type.

-Ремонт типу Попередження, коли функція визначається з типом повернення, який за замовчуванням є int. Також попередити про будь-який оператор повернення без значення повернення у функції, тип повернення якого не є недійсним (падіння з кінця тіла функції вважається поверненням без значення), і про оператор повернення з виразом у функції, чий тип повернення недійсний.

Це попередження увімкнено функцією -Wall .

Як цікавість, подивіться, що робить цей код:

#include <iostream>

int foo() {
   int a = 5;
   int b = a + 1;
}

int main() { std::cout << foo() << std::endl; } // may print 6

Цей код має формально невизначене поведінку, і на практиці він називає конвенцію та залежать від архітектури . У одній конкретній системі з одним конкретним компілятором повернене значення є результатом оцінки останнього вираження, що зберігається в eaxреєстрі процесора цієї системи.

gcc за замовчуванням не перевіряє, чи всі шляхи коду повертають значення, оскільки в цілому цього зробити неможливо. Це передбачає, що ви знаєте, що робите. Розглянемо загальний приклад з використанням перерахувань:

Color getColor(Suit suit) {
    switch (suit) {
        case HEARTS: case DIAMONDS: return RED;
        case SPADES: case CLUBS:    return BLACK;
    }

    // Error, no return?
}

Ви, програміст, знаєте, що, забороняючи помилку, цей метод завжди повертає колір. gcc довіряє, що ви знаєте, що ви робите, так що це не змушує вас ставити віддачу внизу функції.

javac, з іншого боку, намагається перевірити, що всі кодові шляхи повертають значення і видає помилку, якщо він не може довести, що вони всі роблять. Ця помилка обумовлена ​​специфікацією мови Java. Зауважте, що іноді це неправильно, і вам доведеться вводити непотрібну заяву про повернення.

char getChoice() {
    int ch = read();

    if (ch == -1 || ch == 'q') {
        System.exit(0);
    }
    else {
        return (char) ch;
    }

    // Cannot reach here, but still an error.
}

Це філософська різниця. C і C ++ є більш дозволеними та довірливими мовами, ніж Java або C #, тому деякі помилки в нових мовах є попередженнями на C / C ++, а деякі попередження за замовчуванням ігноруються або вимикаються.

Ти маєш на увазі, чому відтікання від кінця функції повернення значення (тобто вихід без явного return) не є помилкою?

По-перше, в C, чи повертає функція щось значиме чи ні, є критичним лише тоді, коли виконуваний код фактично використовує повернене значення. Можливо, мова не хотіла змушувати вас нічого повертати, коли ви знаєте, що все одно не будете користуватися нею.

По-друге, очевидно, мовна специфікація не хотіла змушувати авторів-компіляторів виявляти та перевіряти всі можливі шляхи управління на предмет наявності явного return(хоча у багатьох випадках це не так складно зробити). Крім того, деякі шляхи керування можуть призвести до функцій, що не повертаються - ознака, яка, як правило, не відома компілятору. Такі шляхи можуть стати джерелом дратівливих помилкових позитивів.

Зауважимо також, що C і C ++ відрізняються своїми визначеннями поведінки в цьому випадку. У C ++ просто витікання з кінця функції повернення значення завжди є невизначеною поведінкою (незалежно від того, чи використовує результат функції код виклику). У C це викликає невизначене поведінку, лише якщо код виклику намагається використовувати повернене значення.

За C / C ++ законно не повертатися з функції, яка вимагає повернути щось. Існує ряд випадків використання, наприклад, дзвінок exit(-1)або функція, яка викликає його або кидає виняток.

Компілятор не збирається відкидати легальний C ++, навіть якщо це призводить до UB, якщо ви просите його не робити. Зокрема, ви просите не створювати попереджень . (Gcc все ще вмикає деякі за замовчуванням, але коли їх додано, схоже, вони узгоджуються з новими функціями, а не новими попередженнями для старих функцій)

Зміна за замовчуванням no-arg gcc для надсилання деяких попереджень може стати суттєвою зміною для існуючих сценаріїв або створення систем. Добре розроблені з них або -Wallстосуються попереджень, або перемикайте окремі попередження.

Навчитися використовувати ланцюжок інструментів C ++ є перешкодою для того, щоб навчитися бути програмістом C ++, але ланцюги інструментів C ++, як правило, пишуться експертами та експертами.

Я вважаю, це через старий код (C ніколи не вимагав заяви про повернення, як і C ++). Напевно, величезна база коду спирається на цю "особливість". Але принаймні є -Werror=return-type прапор на багатьох компіляторах (включаючи gcc та clang).

У деяких обмежених та рідкісних випадках може бути корисним стікання з кінця недійсної функції без повернення значення. Як і наступний специфічний для MSVC код:

double pi()
{
    __asm fldpi
}

Ця функція повертає pi за допомогою складання x86. На відміну від складання в GCC, я не знаю, як returnце зробити, не включаючи накладні витрати в результат.

Наскільки я знаю, основні компілятори C ++ повинні випромінювати принаймні попередження щодо недійсного коду. Якщо я зробить тіло pi()порожнім, GCC / Clang повідомить попередження, а MSVC повідомить про помилку.

Люди згадували винятки та exitв деяких відповідях. Це не вагомі причини. Або викидання винятку, або виклик exit, не змусять виконання функції відтікати до кінця. І компілятори це знають: написання заяви про викидання або виклик exitу порожній частині pi()файлу зупинить будь-які попередження чи помилки компілятора.

За яких обставин це не призводить до помилки? Якщо він оголошує тип повернення і щось не повертає, це здається мені помилкою.

Єдиним винятком, про який я можу придумати, є main()функція, яка взагалі не потребує returnоператора (принаймні, на C ++; у мене немає жодного зі стандартів C). Якщо повернення немає, воно буде діяти так, ніби return 0;це остання заява.

Схоже, вам потрібно створити попередження компілятора:

$ gcc -Wall -Wextra -Werror -x c -
int main(void) { return; }
cc1: warnings being treated as errors
<stdin>: In function ‘main’:
<stdin>:1: warning: ‘return’ with no value, in function returning non-void
<stdin>:1: warning: control reaches end of non-void function
$

Це порушення обмеження в c99, але не в c89. Контраст:

c89:

3.6.6.4 returnЗаява

Обмеження

returnЗаява з виразом не повинні з'являтися в функції якого повертається тип void.

c99:

6.8.6.4 returnЗаява

Обмеження

returnЗаява з виразом не повинні з'являтися в функції якого повертається тип void. returnЗаява без вираження повинні з'являтися тільки в функції якого повертається тип void.

Навіть у --std=c99режимі gcc видасть лише попередження (хоча не потрібно вмикати додаткові -Wпрапорці, як того вимагають за замовчуванням або в c89 / 90).

Відредагуйте, щоб додати, що в c89 "досягнення тієї, }яка завершує функцію, еквівалентна виконанню returnоператора без виразу" (3.6.6.4). Однак у c99 поведінка не визначена (6.9.1).