Un buen punto de partida sería POSIX. La especificación POSIX 2008 está disponible en línea aquí:
http://pubs.opengroup.org/onlinepubs/9699919799/
es más accesible (pero a veces menos rigurosa) que el estándar de C, y cubre mucho más que el estándar de C, es decir, la mayor parte de las piezas estandarizadas de Bibliotecas estándar de sistemas similares a Unix.
Si le interesan las implementaciones, lo primero que debe tenerse en cuenta es que el comportamiento descrito por POSIX suele estar dividido (por razones de necesidad y pragmáticas) entre la implementación kernel y la implementación libc del espacio de usuario. Una gran cantidad de las funciones en POSIX (y algunas del estándar C) serán meramente envoltorios para "llamadas al sistema", es decir, transiciones al espacio del kernel para atender la solicitud. En algunas implementaciones de libc, incluso la búsqueda de estos contenedores será difícil, ya que a menudo se generan automáticamente mediante los scripts de compilación y/o se unifican en un solo archivo en lenguaje ensamblador.
La principal (cantidad significativa de código no kernel) subsistemas de la biblioteca estándar son generalmente:
- stdio: En glibc, esto se implementa por la biblioteca del GNU libio, que es una implementación unificada de C stdio y C++ iostream, optimizados para que ninguno de los dos tenga que ralentizarse al ser un contenedor para el otro. Es un gran truco, y el código es difícil de encontrar y seguir. Otras implementaciones (especialmente las BSD, pero también otras bibliotecas en Linux) son mucho más simples y claras de leer. En última instancia, se basan en las funciones subyacentes del descriptor de archivo IO, como
open, read, etc.
- Subprocesos POSIX: En glibc y en uClibc moderno, esto es NPTL. No estoy familiarizado con las implementaciones de subprocesos de los BSD. Otras bibliotecas de Linux carecen de subprocesos o proporcionan sus propias implementaciones basadas principalmente en Linux
clone y futex syscalls.
- Biblioteca de matemáticas: en última instancia, casi todas están basadas en el antiguo código de matemáticas Sun de principios de los 90, pero divergieron mucho. Fdlibm es una buena aproximación de base del código utilizado en libcs modernos.
- Consultas de usuario, grupo, nombre de host (DNS), etc.: esto se maneja a través de libnss en glibc, y directamente en la mayoría de las otras librerías.
- regular la expresión y pegote juego
- Tiempo y gastos de envío
- configuración regional y la conversión de juego de caracteres
- Malloc
Si quieres empezar a leer fuentes de zona horaria, recomendaría que no empiezan con glibc. Es muy grande y difícil de manejar. Si desea leer glibc, tenga en cuenta que gran parte del código se esconde debajo de los árboles de sysdeps y está organizado según la diversidad de sistemas a los que se aplica.
dietlibc es bastante fácil de leer, pero si usted lee su fuente, tenga en cuenta que está lleno de errores de programación C comunes (por ejemplo, utilizando int donde se necesita size_t, no la comprobación de los desbordamientos, etc.). Si se tiene esto en cuenta, puede que no sea una mala elección, ya que ignorar muchos errores/fallas posibles hace que el código sea muy simple.
Dicho esto, para leer fuente de libc, recomendaría cualquiera de los BSD o musl (descargo de responsabilidad: soy el principal autor de musl, así que estoy un poco parcial aquí). Los BSD también tienen la ventaja de que el código del kernel es también extremadamente simple y legible, por lo que si desea leer el código del kernel al otro lado de una llamada al sistema, puede hacerlo también.
Vuelva a abrir. Cerrar esto unilateralmente fue un abuso del poder de los moderadores. Creo que esta pregunta es perfectamente razonable, que puede responderse en el formato SO, y de hecho tengo una respuesta que no pude publicar debido a la desafortunada decisión unilateral de cierre. –
@R ..: Bien, parece que la pregunta ahora está abierta, etiquetándote aquí para que recibas una notificación y veas que la pregunta se volvió a abrir =) – cha0site
@ cha0site: ¡Gracias! –