Vedi, è un esempio completo, funzionante e compilabile. Non esitare a compilarlo tu stesso e testarlo, funziona davvero. Dovresti chiamare il programma da un terminale come questo:

Ora, concentriamoci sulla chiamata di lettura stessa:

La firma di lettura è la seguente (estratta dalle pagine man di Linux):

Primo, l'argomento fd rappresenta il descrittore di file. Ho spiegato un po' questo concetto nel mio articolo sulla forcella.  Un descrittore di file è un int che rappresenta un file aperto, socket, pipe, FIFO, dispositivo, beh, sono molte le cose in cui i dati possono essere letti o scritti, generalmente in modo simile a un flusso. Ne parlerò più approfonditamente in un prossimo articolo.

la funzione open è uno dei modi per dire a Linux: voglio fare cose con il file in quel percorso, per favore trovalo dove si trova e dammi l'accesso ad esso. Ti restituirà questo int chiamato descrittore di file e ora, se vuoi fare qualcosa con questo file, usa quel numero. Non dimenticare di chiamare close quando hai finito con il file, come nell'esempio.

Quindi è necessario fornire questo numero speciale per leggere. Poi c'è l'argomento buf. Dovresti qui fornire un puntatore all'array in cui read memorizzerà i tuoi dati. Infine, conta quanti byte leggerà al massimo.

Il valore restituito è di tipo ssize_t. Tipo strano, non è vero?? Significa "signed size_t", in pratica è un lungo int. Restituisce il numero di byte che legge con successo, o -1 se c'è un problema. Puoi trovare la causa esatta del problema nella variabile globale errno creata da Linux, definita in . Ma per stampare un messaggio di errore, usare perror è meglio in quanto stampa errno per tuo conto.

Nei file normali - e solo in questo caso - read restituirà meno di count solo se hai raggiunto la fine del file. L'array buf che fornisci dovere essere abbastanza grande da contenere almeno il conteggio dei byte, o il tuo programma potrebbe bloccarsi o creare un bug di sicurezza.

Ora, leggere non è utile solo per i file normali e se vuoi sentire i suoi super poteri - Sì, lo so che non è in nessun fumetto Marvel ma ha dei veri poteri - vorrai usarlo con altri flussi come tubi o prese. Diamo un'occhiata a questo:

File speciali di Linux e lettura della chiamata di sistema

Il fatto che read funzioni con una varietà di file come pipe, socket, FIFO o dispositivi speciali come un disco o una porta seriale è ciò che lo rende davvero più potente. Con alcuni adattamenti, puoi fare cose davvero interessanti. In primo luogo, questo significa che puoi letteralmente scrivere funzioni lavorando su un file e usarlo invece con una pipe. È interessante passare i dati senza mai colpire il disco, garantendo le migliori prestazioni.

Tuttavia, questo attiva anche regole speciali. Facciamo l'esempio di una lettura di una riga da terminale rispetto ad un normale file. Quando si chiama read su un file normale, sono necessari solo pochi millisecondi a Linux per ottenere la quantità di dati richiesta.

Ma quando si tratta di terminale, questa è un'altra storia: diciamo che chiedi un nome utente. L'utente sta digitando nel terminale il suo nome utente e preme Invio. Ora segui il mio consiglio sopra e chiami read con un grande buffer come 256 byte.

Se la lettura funzionava come con i file, attendeva che l'utente digitasse 256 caratteri prima di tornare before! Il tuo utente aspetterebbe per sempre e poi sfortunatamente ucciderebbe la tua applicazione. Non è certamente quello che vuoi, e avresti un grosso problema.

Ok, potresti leggere un byte alla volta ma questa soluzione alternativa è terribilmente inefficiente, come ti ho detto sopra. Deve funzionare meglio di così.

Ma gli sviluppatori Linux pensavano di leggere diversamente per evitare questo problema:

• Quando leggi i file normali, cerca il più possibile di leggere i byte di conteggio e otterrà attivamente i byte dal disco se necessario.
• Per tutti gli altri tipi di file, tornerà non appena ci sono alcuni dati disponibili e al massimo conta i byte:
  1. Per i terminali, è in genere quando l'utente preme il tasto Invio.
  2. Per i socket TCP, non appena il tuo computer riceve qualcosa, non importa la quantità di byte che ottiene.
  3. Per FIFO o pipe, è generalmente la stessa quantità di ciò che ha scritto l'altra applicazione, ma il kernel Linux può fornire meno alla volta se è più conveniente.

Così puoi chiamare in sicurezza con il tuo buffer da 2 KiB senza restare bloccato per sempre. Nota che può anche essere interrotto se l'applicazione riceve un segnale. Poiché la lettura da tutte queste fonti può richiedere secondi o addirittura ore - fino a quando l'altra parte non decide di scrivere, dopotutto - essere interrotti da segnali permette di smettere di rimanere bloccati per troppo tempo.

Questo ha anche uno svantaggio: quando vuoi leggere esattamente 2 KiB con questi file speciali, dovrai controllare il valore di ritorno di read e chiamare read più volte. read raramente riempirà l'intero buffer. Se la tua applicazione utilizza segnali, dovrai anche verificare se la lettura non è riuscita con -1 perché è stata interrotta da un segnale, utilizzando errno.

Lascia che ti mostri come può essere interessante utilizzare questa proprietà speciale di read: