Marshalling ABI et types de valeurs
Statut documentaire : reference — voir Maturité et preuves.
Deux niveaux à distinguer
L'ABI possède un vocabulaire de descripteurs et un sous-ensemble d'exécution implémenté. Ils ne sont pas encore identiques.
Le vocabulaire peut nommer :
null, boolean, integer, float, string, handle, array, record, void,
pointer, callback, i8/u8, i16/u16, i32/u32, i64/u64, f32/f64, bytes
Le manifeste peut donc décrire une forme cible plus large, mais le builder et l'executor génériques actuels n'en certifient qu'un sous-ensemble.
Entrées actuellement certifiées
i32
La valeur est contrôlée en plage avant copie dans le record packed. La taille déclarée doit être de quatre octets.
Pointeur
La taille doit correspondre au pointeur de l'hôte. La valeur nulle n'est acceptée que si le descripteur autorise nullable.
Handle
Physiquement de taille pointeur, mais sémantiquement distinct : le handle référence un objet géré par l'ABI et participe donc à l'ownership et au release.
Null
La représentation générique contient un type null explicite. Le builder courant l'accepte pour les paramètres pointeur/handle nullable.
Résultats actuellement certifiés
Le generic executor décode void, i32, pointeur et handle. Les autres types ne doivent pas être présentés comme disponibles via ce chemin tant que packing, décodage, ownership et tests ne sont pas implémentés.
Directions de paramètres
Le manifeste reconnaît in, out et inout, mais le builder courant n'exécute que in. Les autres directions échouent avant l'appel natif.
Chaînes et tableaux
Strings, arrays, records, bytes et callbacks font déjà partie du vocabulaire ABI. Ils ne sont pas encore certifiés par l'implémentation générique de marshalling inspectée dans cette passe.
Le prochain incrément de certification est détaillé dans Chaînes UTF-8 et Buffers d'octets. Les tableaux restent un contrat distinct et ultérieur.
Une future implémentation doit préciser représentation physique, encodage, nullabilité, longueur, allocator, release, ownership imbriqué, projection local/RPC et tests de contrat.
Règle recommandée pour les bindings
Le générateur ne doit jamais déduire qu'un type est supporté uniquement parce qu'il existe dans l'enum ABI. Il doit consommer un manifeste/capability set certifié, ou échouer explicitement lorsque la signature publique exige un type non supporté.