Dlaczego wypływ z końca funkcji innej niż void bez zwracania wartości nie powoduje błędu kompilatora?

Odkąd wiele lat temu zdałem sobie sprawę, że domyślnie nie powoduje to błędu (przynajmniej w GCC), zawsze zastanawiałem się, dlaczego?

Rozumiem, że możesz wysyłać flagi kompilatora, aby wygenerować ostrzeżenie, ale czy nie powinno to zawsze być błędem? Dlaczego ma sens, aby funkcja nieważna, która nie zwraca wartości, była prawidłowa?

Przykład zgodnie z prośbą w komentarzach:

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

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

... kompiluje się.

Standardy C99 i C ++ nie wymagają funkcji do zwracania wartości. Brakująca instrukcja return w funkcji zwracającej wartość zostanie zdefiniowana (do zwrócenia 0) tylko w mainfunkcji.

Uzasadnienie obejmuje stwierdzenie, że sprawdzenie, czy każda ścieżka kodu zwraca wartość, jest dość trudne, a wartość zwracaną można ustawić za pomocą wbudowanego asemblera lub innych skomplikowanych metod.

Z wersji roboczej C ++ 11 :

§ 6.6.3 / 2

Wypłynięcie z końca funkcji [...] powoduje niezdefiniowane zachowanie w funkcji zwracającej wartość.

§ 3.6.1 / 5

Jeśli kontrola osiągnie koniec mainbez napotkania return instrukcji, efektem jest wykonanie

return 0;

Zauważ, że zachowanie opisane w C ++ 6.6.3 / 2 nie jest takie samo w C.

gcc da ci ostrzeżenie, jeśli wywołasz go z opcją -Wreturn-type.

-Wreturn-type Ostrzegaj za każdym razem, gdy funkcja jest zdefiniowana z typem zwracanym, który domyślnie int. Ostrzegaj również o każdej instrukcji return bez wartości zwracanej w funkcji, której typ zwrotu nie jest void (wypadnięcie z końca ciała funkcji jest uważane za zwracające bez wartości) oraz o instrukcji return z wyrażeniem w funkcji, której return-type is void.

To ostrzeżenie jest włączane przez -Wall .

Jako ciekawostkę spójrz, co robi ten kod:

#include <iostream>

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

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

Ten kod ma formalnie niezdefiniowane zachowanie iw praktyce wywołuje zależne od konwencji i architektury . W jednym konkretnym systemie, z jednym konkretnym kompilatorem, wartość zwracana jest wynikiem oceny ostatniego wyrażenia, przechowywanej w eaxrejestrze procesora tego systemu.

gcc domyślnie nie sprawdza, czy wszystkie ścieżki kodu zwracają wartość, ponieważ generalnie nie można tego zrobić. Zakłada, że ​​wiesz, co robisz. Rozważmy typowy przykład z wykorzystaniem wyliczeń:

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

    // Error, no return?
}

Ty programista wiesz, że poza błędem ta metoda zawsze zwraca kolor. gcc ufa, że ​​wiesz, co robisz, więc nie zmusza cię do umieszczania powrotu na dole funkcji.

Z drugiej strony javac próbuje zweryfikować, czy wszystkie ścieżki kodu zwracają wartość i zgłasza błąd, jeśli nie może udowodnić, że wszystkie to robią. Ten błąd jest wymagany przez specyfikację języka Java. Zauważ, że czasami jest to błędne i musisz wstawić niepotrzebną instrukcję powrotu.

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

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

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

To filozoficzna różnica. Języki C i C ++ są bardziej liberalne i ufają bardziej niż Java lub C #, dlatego niektóre błędy w nowszych językach są ostrzeżeniami w C / C ++, a niektóre ostrzeżenia są domyślnie ignorowane lub wyłączane.

Masz na myśli, dlaczego wypłynięcie z końca funkcji zwracającej wartość (tj. Wyjście bez jawności return) nie jest błędem?

Po pierwsze, w C to, czy funkcja zwraca coś znaczącego, czy nie, jest krytyczne tylko wtedy, gdy wykonujący kod faktycznie używa zwróconej wartości. Może język nie chciał zmusić Cię do zwrotu czegokolwiek, kiedy wiesz, że i tak nie będziesz go używać przez większość czasu.

Po drugie, najwyraźniej specyfikacja języka nie chciała zmusić autorów kompilatora do wykrycia i zweryfikowania wszystkich możliwych ścieżek kontrolnych pod kątem obecności jawnego return(chociaż w wielu przypadkach nie jest to takie trudne). Ponadto niektóre ścieżki kontrolne mogą prowadzić do funkcji niezwracających - cecha, która jest generalnie nieznana kompilatorowi. Takie ścieżki mogą stać się źródłem irytujących fałszywych alarmów.

Zauważ również, że C i C ++ różnią się definicjami zachowania w tym przypadku. W C ++ samo wypłynięcie z końca funkcji zwracającej wartość jest zawsze niezdefiniowanym zachowaniem (niezależnie od tego, czy wynik funkcji jest używany przez wywołujący kod). W C powoduje to niezdefiniowane zachowanie tylko wtedy, gdy kod wywołujący próbuje użyć zwróconej wartości.

W C / C ++ legalne jest, aby nie powracać z funkcji, która twierdzi, że coś zwraca. Istnieje wiele przypadków użycia, takich jak wywołanie exit(-1)lub funkcja, która ją wywołuje lub zgłasza wyjątek.

Kompilator nie odrzuci legalnego C ++, nawet jeśli prowadzi to do UB, jeśli o to poprosisz. W szczególności prosisz o nie generowanie ostrzeżeń . (Gcc nadal domyślnie włącza niektóre, ale po dodaniu wydaje się, że są one zgodne z nowymi funkcjami, a nie nowymi ostrzeżeniami dla starych funkcji)

Zmiana domyślnego gcc bezargumentowego, aby emitował pewne ostrzeżenia, może być przełomową zmianą dla istniejących skryptów lub stworzyć systemy. Dobrze zaprojektowane -Walli radzą sobie z ostrzeżeniami lub przełączają poszczególne ostrzeżenia.

Nauka korzystania z łańcucha narzędzi C ++ jest barierą w nauce bycia programistą C ++, ale łańcuchy narzędzi C ++ są zazwyczaj pisane przez ekspertów i dla nich.

Uważam, że jest to spowodowane starszym kodem (C nigdy nie wymagało instrukcji powrotu, podobnie jak C ++). Prawdopodobnie istnieje ogromna baza kodu zależna od tej „funkcji”. Ale przynajmniej jest -Werror=return-type flaga na wielu kompilatorach (w tym gcc i clang).

W niektórych ograniczonych i rzadkich przypadkach może być przydatne wypłynięcie z końca funkcji, która nie jest pusta, bez zwracania wartości. Podobnie jak następujący kod specyficzny dla MSVC:

double pi()
{
    __asm fldpi
}

Ta funkcja zwraca liczbę pi przy użyciu zestawu x86. W przeciwieństwie do montażu w GCC, nie znam żadnego sposobu returnna zrobienie tego bez angażowania narzutu w wyniku.

O ile wiem, główne kompilatory C ++ powinny emitować przynajmniej ostrzeżenia dla pozornie nieprawidłowego kodu. Jeśli uczynię pi()treść pustą, GCC / Clang zgłosi ostrzeżenie, a MSVC zgłosi błąd.

Ludzie wspominali o wyjątkach i exitw niektórych odpowiedziach. To nie są ważne powody. Albo rzuca wyjątek, lub wywołanie exit, będzie nie sprawiają, że wykonanie funkcji odpływać do końca. Kompilatory to wiedzą: napisanie instrukcji throw lub wywołanie exitpustej treści polecenia pi()zatrzyma wszelkie ostrzeżenia lub błędy kompilatora.

W jakich okolicznościach nie powoduje to błędu? Jeśli deklaruje typ zwracany i nic nie zwraca, brzmi to dla mnie jak błąd.

Jedynym wyjątkiem, o którym przychodzi mi do głowy, jest main()funkcja, która w ogóle nie potrzebuje returninstrukcji (przynajmniej w C ++; nie mam pod ręką żadnego ze standardów C). Jeśli nie ma powrotu, będzie działać tak, jakby return 0;była ostatnią instrukcją.

Wygląda na to, że musisz podkręcić ostrzeżenia kompilatora:

$ 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
$

Jest to naruszenie ograniczenia w c99, ale nie w c89. Kontrast:

c89:

3.6.6.4 returnOświadczenie

Ograniczenia

returnOświadczenie o wyrażeniu nie powinny pojawiać się w funkcji, których typ jest powrót void.

c99:

6.8.6.4 returnOświadczenie

Ograniczenia

returnOświadczenie o wyrażeniu nie powinny pojawiać się w funkcji, których typ jest powrót void. returnOświadczenie bez wyrazu powinna pojawić się tylko w funkcji, których typ jest powrót void.

Nawet w --std=c99trybie gcc wyśle ​​tylko ostrzeżenie (chociaż bez potrzeby włączania dodatkowych -Wflag, jak jest to wymagane domyślnie lub w c89 / 90).

Edytuj, aby dodać, że w c89 „osiągnięcie tego, }co kończy funkcję, jest równoważne wykonaniu returninstrukcji bez wyrażenia” (3.6.6.4). Jednak w c99 zachowanie jest niezdefiniowane (6.9.1).