[C] warning: ISO C90 does not support ...

Hi!

Code:

#define _GNU_SOURCE   
#include <stdio.h>   
#include <stdlib.h>   
   
int main( void )   
{   
    FILE *fp;   
    char *line = NULL;   
    size_t len = 0;  
    ssize_t read;  
  
    fp = fopen( "/etc/motd", "r" );  
    if ( fp == NULL)  
        exit( EXIT_FAILURE );  
  
    while ( ( read = getline( &line, &len, fp ) ) != -1 ) {  
        printf( "Retrieved line of length %zu:\n", read );  
        printf( "%s", line );  
    }  
  
    if ( line )  
        free( line );  
    exit( EXIT_SUCCESS );  
}

Wenn ich diesen Code kompiliere, bekomme ich diese Fehlermeldung:
"warning: ISO C90 does not support the ‘z’ printf length modifier"

- kann ich solche Meldungen ignorieren?
- gibt es einen Ersatz für "%zu"?
- warum wird hier exit und nicht return verwendet? ( man-getline-Beispiel )

für "%zu" habe ich einen workaround gefunden:

"printf( "Retrieved line of length %d:\n", (int) read );"

ist ja auch die main-function..danach wirds nunmal dunkel

1: #define _GNU_SOURCE
unterbindet wohl die fehlermeldung. gnu c hat die funktion, ansi c nicht

Zitat von lama007

Zu diesem Beispiel habe ich noch eine Frage:

Irgendwo habe ich gelesen, das getline() nicht zum Umfang von ANSI C gehört,
darum habe ich mir erwartet, dass ich beim Kompilieren mit den Optionen -ansi -pedantic eine Fehlermeldung bekomme.
Stimmen meine Erwartungen bezüglich dieser Optionen nicht oder gehört getline() doch zum Umfang von ANSI C?

Wenn eine Funktion nicht zum ansi c90 standard gehört sollte dir dieser Aufruf ein Warning liefern (weil funktion undefined).
ein #define _GNU_SOURCE "deaktiviert" solche Warnings - man darf halt dann nicht vergessen dass ein solches Programm dann nicht mehr c90 kompatibel ist - es wird u.U. nicht mehr mit einer anderen Stdlib als der GNU C lib kompilierbar sein.
Normalerweise steht übrigens in den Manpages ob eine Funktion im c90 standard vorkommt, bzw. wenn es abweichende Implementierungen gibt (ganz am Ende meistens - "CONFORMING TO" o.Ä.)

In der Manpage vom getline steht übrigens:

Zitat

CONFORMING TO
Both getline() and getdelim() are GNU extensions. They are available since libc 4.6.27.

Zitat von lama007

Muss man immer die man-pages der Funktionen studieren, um zu wissen, ob es free() braucht oder nicht?

Ja.

Zitat von lama007

Zur Speicherbefreiung habe ich folgenden Satz gefunden:
"Falls ein Speicherbereich freigegeben wird, der nicht zuvor mit malloc(), calloc() oder realloc() alloziiert wurde, kann dies katastrophale Folgen haben."

Wo hast du denn den Satz her? Hört sich ja nach Weltuntergang an...

Zitat

free() frees the memory space pointed to by ptr, which must have been returned by a previous call to malloc(), calloc() or realloc(). Otherwise, or if free(ptr) has already been called before, undefined behaviour occurs. If ptr is NULL, no operation is performed.

Sagt "man 3 free". Man könnte natürlich annehmen dass wenn dieses Problem im Programm einer Kernkraftwerks-Steuerung zuschlägt tatsächlich katastrophale Folgen entstehen könnten, aber ich halte das etwas weit hergeholt

Zitat von lama007

wenn ich keinen Speicher von Hand reserviere, brauche ich ihn normalerweise auch nicht selbst befreien, außer bei ein paar Funktionen?

Sollst du eigentlich auch nicht, weil du ja nicht weißt was dann passiert.

Das ganze lässt sich oft recht leicht anstellen - initialisierst du zb. so einen Pointer mit NULL kannst du recht sicher davon ausgehen dass du gefahrlos free() aufrufen kannst, weil der Pointer ja dann entweder NULL ist oder auf einen passenden Speicherbereich zeigt.

Ein 2. call an free() ist dann natürlich wieder anstrengend, vor allem wenns dann mit signals losgeht - wo/wann wurde SIGXY called? vor oder nach dem free, etc. Das hat bei mir schon paarmal in geendet...