2012-04-02 18 views
7

Sono interessato al funzionamento interno della libreria C standard. Ho trovato un buon libro su una possibile implementazione - ma sto cercando una spiegazione più approfondita dell'intera libreria standard e degli standard (come POSIX) - la definizione di questi standard nella libreria standard.Funzionamento interno della libreria standard C

Le bozze di C sono molto utili ma non molto piacevoli da leggere. C'è altra letteratura su questo argomento?

  • standard-Biblioteca-PJ-Plauger 1991
  • FreeBSD
  • GNU uomo
  • C progetto (s)

Albertus

+7

Riapri. Chiudere unilateralmente questo era un abuso del potere dei moderatori. Credo che questa domanda sia perfettamente ragionevole, disponibile nel formato SO, e infatti ho una risposta che mi è stata impedita di pubblicare dalla sfortunata decisione unilaterale di chiudere. –

+0

@R ..: Giusto, sembra che la domanda sia ora aperta, taggandoti qui così ricevi una notifica e vedi che la domanda è stata riaperta =) – cha0site

+0

@ cha0site: Grazie! –

risposta

6

Un buon punto di partenza sarebbe POSIX. La specifica POSIX 2008 è disponibile on-line qui:

http://pubs.opengroup.org/onlinepubs/9699919799/

è più accessibile (ma a volte meno rigorosa) rispetto allo standard C, e copre molto di più che lo standard C, vale a dire la maggior parte delle parti standardizzate di Librerie standard dei sistemi Unix.

Se si è interessati alle implementazioni, la prima cosa da tenere presente è che il comportamento descritto da POSIX viene solitamente diviso (per necessità e motivi pragmatici) tra l'implementazione del kernel e l'implementazione libc dello spazio utente. Un gran numero di funzioni in POSIX (e alcune dello standard C) saranno semplicemente wrapper per "system calls", cioè transizioni in kernelspace per soddisfare la richiesta. Su alcune implementazioni di libc, anche trovare questi wrapper sarà difficile, dato che spesso vengono generati automaticamente dagli script di build e/o unificati in un singolo file di linguaggio assembly.

Il principale (quantità significativa di codice non-kernel) sottosistemi della libreria standard sono generalmente:

  • stdio: In glibc, ciò viene realizzato dalla libreria GNU libio, che è un'implementazione unificata di C iostream di stdio e C++, ottimizzati in modo che nessuno dei due debba essere rallentato essendo un wrapper per l'altro. È un grosso problema e il codice è difficile da trovare e seguire. Altre implementazioni (in particolare i BSD, ma anche altre libbie su Linux) sono molto più semplici e chiare da leggere. Alla fine si basano sulle funzioni di IO del descrittore di file sottostanti come open, read, ecc.
  • Thread POSIX: su glibc e su moderno uClibc, questo è NPTL. Non ho familiarità con le implementazioni dei thread di BSD. Altre librerie di Linux mancano di thread o forniscono le loro implementazioni basate principalmente su Linux clone e sulle syscalls futex.
  • Libreria matematica: in definitiva, quasi tutti si basano sul vecchio codice matematico Sun dei primi anni '90, ma sono molto divergenti. Fdlibm è una buona approssimazione di base del codice usato nelle libc moderne.
  • Ricerca utente, gruppo, nome host (DNS), ecc. Questa viene gestita tramite libnss in glibc e direttamente nella maggior parte delle altre libbie.
  • regolare espressione e glob corrispondenza
  • Tempo di spedizione
  • Locale e la conversione charset
  • Malloc

Se si desidera iniziare la lettura di fonti fuso orario, consiglio che non inizia con glibc. È molto grande e ingombrante. Se vuoi leggere glibc, tieni presente che un sacco di codice si nasconde sotto gli alberi sysdeps ed è organizzato in base alla diversità dei sistemi a cui è applicabile.

dietlibc è abbastanza leggibile, ma se leggete la sua fonte, essere consapevoli del fatto che è pieno di errori comuni di programmazione C (per esempio usando int in cui è necessario size_t, non controllare per overflow, ecc). Se si tiene presente questo, potrebbe non essere una cattiva scelta, dal momento che ignorare un sacco di possibili errori/fallimenti tende a rendere il codice molto semplice.

Detto questo, per la lettura della sorgente di libc, consiglierei uno dei BSD o musl (disclaimer: io sono l'autore principale di musl quindi sono un po 'di parte). I BSD hanno anche il vantaggio che il codice kernelspace è anche estremamente semplice e leggibile, quindi se vuoi leggere il codice del kernel sull'altro lato di una chiamata di sistema, puoi farlo anche tu.

+0

Ciao Grazie per questa interessante risposta (e sblocco). Dopo aver letto un po 'le specifiche POSIX ho notato che questa documentazione è molto più facile da leggere rispetto allo standard C, perché è focalizzata sulla definizione standard. Per me, la pagina sorgente/documentazione BSD e il progetto della biblioteca musl sono due buoni punti di partenza. Anche il backend di syscall di queste librerie è interessante. Albertus – swaechter

+0

_unified implementazione di C stdio e C++ iostream_ - non 'g ++' fornisce la propria implementazione 'iostream'? –

+0

@Maxim: Sì, ma è progettato in modo che il layout binario delle classi sia uguale al layout binario delle strutture in glibc stdio e gli stessi oggetti siano utilizzati per entrambi in questo caso ... –

5

In "C: un manuale di riferimento, Fifth Edition "di Harbison & Steele, la seconda parte del libro è dedicata alla libreria C Standard (parte 2: capitoli 10-24).

http://careferencemanual.com

Il documento Giustificazione di C99 non ha coperto la libreria C, ma l'ANSI C89 Rationale copre nel suo capitolo 4. V'è una copia del documento qui:

http://www.lysator.liu.se/c/rat/title.html

+0

Ciao Grazie per la risposta, l'argomento sulla "definizione" C89 è un buon aiuto. – swaechter

Problemi correlati