Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

273
Vistas
¿Qué tan factible es virtualizar las interfaces FILE* de C?

A menudo me he dado cuenta de que habría podido resolver problemas prácticos en C con elegancia si hubiera habido una forma de crear un ' FILE virtual' y adjuntar las devoluciones de llamada necesarias para eventos como búfer lleno, entrada solicitada, cierre, vaciado. Entonces debería ser posible utilizar una gran parte de las funciones stdio.h , por ejemplo, fprintf sin cambios. ¿Existe un marco que permita hacer esto? Si no, ¿es factible con un esfuerzo moderado, al menos en algunas plataformas?

Las posibles aplicaciones serían:

  • Para escribir o leer desde una región dinámica o estática de la memoria.
  • Para escribir en varios archivos en paralelo.
  • Para leer de un hilo o co-rutina generando datos.
  • Para aplicar un filtro a otro FILE (virtual o real).
  • Compatibilidad con formatos de archivo con direccionamiento indirecto (como #include ).
  • Preprocesador de CA (?).

Estoy menos interesado en soluciones para casos específicos que en un marco que le permita crear su propio FILE . Tampoco estoy buscando un sistema de archivos virtual, sino FILE* virtuales que pueda pasar al CRT.

Para mi desilusión, nunca he visto nada por el estilo; por lo que puedo ver, C11 considera que FILE depende completamente del implementador del lenguaje, lo que quizás sea razonable si uno desea mantener las especificaciones del lenguaje (+biblioteca) pequeñas pero tristes si lo compara con flujos de E/S de Java.

Estoy seguro de que los FILE virtuales deben ser posibles con cualquier implementación de código abierto (totalmente) del tiempo de ejecución de C, pero imagino que puede haber una gran cantidad de detalles que lo hacen más complicado de lo que parece, y si ya se ha hecho sería una pena reduplicar el esfuerzo. También sería muy preferible no tener que modificar el código CRT. Sin el código abierto, uno podría ser capaz de aplicar ingeniería inversa a las funciones proporcionadas, pero me temo que el resultado sería demasiado vulnerable a los cambios en las funciones no compatibles, a menos que hubiera un compromiso con un conjunto de interfaces. Supongo también que cualquier sistema para el que se pueda escribir un controlador de dispositivo permitiría crear un dispositivo virtual, pero sospecho que es innecesariamente de bajo nivel y requiere que uno escriba código privilegiado.

Tengo que admitir que si bien tengo un código que se habría beneficiado de los FILE virtuales, no tengo ningún requisito actual para ello; sin embargo, es algo sobre lo que me he preguntado muchas veces y que imagino podría ser de interés para otros.

Esto es algo similar a a-reader-interface-that-consumes-files-and-char-in-c , pero allí el interrogador no esperaba devolver un FILE virtual ; la respuesta, sin embargo, usando fmemopen , sí.

over 4 years ago · Santiago Trujillo
1 Respuestas
Responde la pregunta

0

No existe una interfaz C estándar para crear ARCHIVOS virtuales, pero las bibliotecas estándar GNU y BSD incluyen una. En Linux (glibc), puede usar fopencookie ; en la mayoría de los sistemas *BSD, funopen (incluido Mac OS X ). (Ver Nota 1)

Las dos interfaces son similares pero ligeramente diferentes en algunos detalles. Sin embargo, suele ser muy sencillo adaptar el código escrito para una interfaz a otra.

Estas no son virtualizaciones completas. Asociaron el FILE* con cuatro devoluciones de llamada y un contexto void* (la "cookie" en fopencookie ). Las devoluciones de llamada son de read , write , seek y close ; no hay devoluciones de llamada para operaciones de flush o de tell . Aún así, esto es suficiente para muchos adaptadores FILE* simples.

Para ver un ejemplo simple, vea las dos respuestas a Escribir simultáneamente en dos flujos .


Notas:

  1. funopen se deriva de "abierto funcional", no de "archivo sin abrir".
over 4 years ago · Santiago Trujillo Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda