WAH: un intérprete de WebAssembly hecho en un solo archivo de cabecera

Hacía tiempo que no creaba una biblioteca en C. Es, literalmente, un intérprete de WebAssembly que contiene todo en un solo archivo de cabecera de C. Claro que no es solo un intérprete sin más, sino que además incluye:

• Soporta al 100% la especificación WebAssembly 3.0. Sí, incluye todo eso de GC y demás.
• WebAssembly tiene una opción llamada perfil determinista (deterministic profile) para que produzca exactamente los mismos resultados en cualquier entorno, y este intérprete la implementa. Por eso es útil para obtener resultados reproducibles.
• Tiene optimizaciones específicas por arquitectura para x86-64 y AArch64 NEON.
• Incluye las funciones necesarias para hacer sandboxing de código no confiable. Soporta funciones como fuel metering, donde la ejecución consume "combustible" por instrucción y se detiene cuando este se agota; también permite interrumpir la ejecución después de cierto tiempo y controlar el uso de memoria.
• La API está diseñada para poder reanudar la ejecución incluso después de detenerla en medio del proceso.
• Permite generar módulos de WebAssembly solo con código o enlazar varios módulos dentro de uno solo.
• Se pueden restringir funciones tanto en tiempo de compilación (reduciendo el código compilado) como en tiempo de ejecución.
• Fue diseñado desde el principio con el objetivo de fijar el ABI. Las estructuras de datos pueden asignarse en la pila de C, pero su layout está fijado de antemano para que el ABI no se rompa aunque suba la versión.
• Además de todo eso, tiene una cantidad casi exagerada de pruebas y se le ha hecho fuzz testing de forma intensiva. (De hecho, el fuzzer sigue corriendo ahora mismo...)

Originalmente iba a ser parte de otro proyecto, así que no pensaba hacerlo con este nivel de exigencia, pero para ejecutar las pruebas de la implementación de referencia de WebAssembly (llamadas spectest) al final hubo que implementar todo... y de algún modo terminé con una implementación al 100%. ¿Cómo acabó pasando esto?

Siguiendo la tendencia actual, el código se escribió al principio con Gemini CLI y, a partir de la mitad del proyecto, con Claude Code y a veces Codex; para la planificación usé principalmente Codex. En lo personal, también fue un proyecto para demostrar que los agentes de código pueden desenvolverse bastante bien incluso en programación de sistemas hardcore, siempre que se les sepa dirigir. También quería que sirviera como contraejemplo a la idea de que con vibe coding sale algo que parece convincente, pero por dentro está hecho un desastre.

[ipeng]

Si la especificación para probar es clara, parece que funciona bastante bien un enfoque de armar el flujo de trabajo con un agente de código para hacerlo converger. También me vienen a la mente casos como vinext y pretext.

Cambiando de tema, ¿podrían revisar una vez el serving de CSS del journal...? Aunque ya pasó bastante tiempo, hay muchos buenos artículos que me gustaría compartir con gente cercana, pero si entras desde escritorio el CSS no carga ;_;

[lifthrasiir]

El servidor que servía el CSS murió T_T. Lo siento, pero por el momento por favor usen Wayback Machine...