El párrafo citado ya lo dice bastante bien.

Un entorno de ejecución alojado también es independiente, pero no al revés. Un compilador solo necesita proporcionar una implementación independiente. gcc, por ejemplo, es estrictamente independiente, ya que la biblioteca estándar no está incluida. Sin embargo, asume que está disponible cuando se compila para un entorno alojado (el valor predeterminado), suponiendo que lib esté disponible en el sistema (como glibc). Ver aquí

En pocas palabras, independiente es solo el idioma. No es necesario admitir ninguna biblioteca y solo algunos encabezados (principalmente para tipos comunes y cosas específicas de implementación como límites numéricos, etc.). Esto implica que no es necesario que exista la biblioteca estándar, ni tampoco los encabezados correspondientes. Reason es un entorno independiente que probablemente no tendrá tales funciones como archivos, visualización, etc. Se utiliza para núcleos, integrados sin sistema operativo, etc.

Tenga en cuenta que gcc, por ejemplo, si compila para un entorno alojado ( -fhosted ), asumirá que las funciones utilizadas en la biblioteca estándar tienen el significado correspondiente y podrían aplicar optimizaciones muy agresivas (tiene muchas de esas funciones integradas). Para independiente, en realidad no lo hace, por lo que puede usar una función strcmp , por ejemplo, con una semántica completamente diferente. Sin embargo, asume que existen las funciones mem..., ya que se utilizan para el código normal, por ejemplo, la asignación de estructuras.

Por lo tanto, si construye para metal desnudo, siempre debe pasar -ffreestanding .

Si una implementación alojada se llama a sí misma independiente , obviamente ya no es una implementación alojada . Sin embargo, una vez que se llama a sí mismo alojado , tiene que proporcionar todas las facilidades requeridas por el estándar y no se le permite implementar solo maniquíes, sino que tiene que proporcionar la semántica definida en el estándar.

Solo para dejarlo claro: la sección citada permite que un entorno independiente omita todas las funciones de la biblioteca, excepto los pocos encabezados enumerados. Por lo tanto, puede proporcionar cualquier otra biblioteca y usar los mismos nombres, pero hacer lo que quiera. Como esa no sería la biblioteca estándar, no hay necesidad de cumplimiento.

5.1.2.1 establece además que "Cualquier instalación de biblioteca disponible para un programa independiente, que no sea el conjunto mínimo requerido por la cláusula 4, está definida por la implementación". Eso apoya mi declaración. Nota al margen: tampoco requiere main() como punto de entrada del programa.

Las implementaciones independientes alojadas respectivamente que define el estándar son definiciones mínimas . Ambas variantes son el mínimo común denominador de lo que razonablemente se puede implementar en una amplia gama de sistemas reales.

La razón para definir estos conjuntos mínimos y factibles es especificar cómo debe verse un programa que se dirija a uno de los dos tipos para poder compilar y ejecutar con el resultado esperado en todas las implementaciones ideales que se ajusten al tipo respectivo.

Un programa que se ajuste estrictamente al estándar (es decir, a cualquiera de los dos) es máximamente portátil.

No hace falta decir que las implementaciones realmente existentes, tanto independientes como alojadas, generalmente brindan una gran cantidad de extensiones, lo cual está bien en lo que respecta al estándar, con la única advertencia de que las extensiones no deben invalidar un programa estrictamente conforme.

Volviendo a su pregunta: la distinción que hace el estándar, la teoría, es clara. Las implementaciones realmente existentes , la práctica, se encuentran en un amplio espectro entre y más allá de los requisitos mínimos del estándar, pero están sujetas a la cláusula "no debe cambiar el comportamiento" con respecto a los programas estrictamente conformes (dirigidos a implementaciones alojadas o independientes y que no dependen de ninguna extensión).

Por cierto, sus ejemplos con respecto a las funciones ficticias de la biblioteca estándar son correctos: para implementaciones independientes, estos son solo un caso divertido de extensiones permitidas: ningún programa estrictamente conforme dirigido a entornos independientes los llamaría de todos modos. Como parte de un entorno alojado, serían conformes pero inútiles. (En realidad, uno puede encontrarse con situaciones como esa cuando se agotan ciertos recursos del sistema, o podrían ser implementaciones de prueba).

Hay muchos tipos de implementaciones de C, dirigidas a muchos tipos de plataformas de ejecución diferentes, muchas de las cuales pueden proporcionar una variedad de características útiles y garantías que otras no pueden. Los autores del Estándar decidieron que, en la mayoría de los casos, debería ser lo suficientemente obvio qué tipo de características y garantías deberían proporcionar las implementaciones dirigidas a varias plataformas y campos de aplicación, y cómo deberían proporcionarse, de modo que no habría necesidad de tener un estándar. preocuparse por tales detalles. Por otro lado, la cantidad de aplicaciones que requerirían cosas como E/S de archivos y la cantidad de plataformas que podrían proporcionarlas fueron suficientes para justificar el reconocimiento como "especiales" de aquellas implementaciones que incluyeron tales características.

En general, las implementaciones diseñadas para un uso independiente se podrán usar en plataformas que no podrían manejar de manera útil una implementación alojada. Si bien el Estándar impone algunos requisitos más allá de lo que sería práctico en algunas de las plataformas C más pequeñas, algunas implementaciones de C casi conformes pueden emplearse de manera bastante útil en procesadores con solo almacenamiento suficiente para contener 256 instrucciones y 16 bytes de variables. Si algo como un dispositivo digital de termómetro/temporizador de cocina no tiene un sistema de archivos o una consola, ¿por qué debería desperdiciar almacenamiento en cosas como descriptores para stdout?

Además, debido a que el estándar no define ningún medio estándar por el cual las aplicaciones independientes puedan realizar operaciones de E/S, y debido a que las diferentes plataformas manejan las operaciones de E/S de manera diferente, las aplicaciones casi independientes serán el objetivo de una plataforma o rango de plataformas de destino en particular. Una implementación alojada que no exponga las características naturales ni las garantías que proporcionaría la plataforma subyacente podría ser útil para ejecutar programas que no requieran tales características o garantías. Sin embargo, no es posible que un programa integrado haga casi nada sin usar características y garantías específicas de la plataforma y, por lo tanto, una implementación independiente que no permitiera a un programador acceder a tales cosas no podría hacer mucho. Las implementaciones de calidad deberían permitir a los programadores usar cualquier característica o garantía que pueda ayudarlos a lograr lo que necesitan hacer, aunque algunas pueden requerir el uso de opciones de compilación para garantizar que no hagan nada extraño. Por alguna razón, se ha puesto de moda considerar una decisión del Comité de Normas de que puede haber algunas implementaciones y campos de aplicación donde el valor de una función o garantía no justificaría el costo, como una indicación de que los programadores no deben esperar que las implementaciones proporcionar una característica o garantía que sería útil en la programación de bajo nivel y que la plataforma proporcionaría como un costo esencialmente cero.