Buffers d'octets et charges binaires

Statut documentaire : architecture — voir Maturité et preuves.

Éléments confirmés aujourd'hui

bytes existe déjà dans le vocabulaire des descripteurs ABI et est reconnu par le chargeur de manifeste. Le buffer générique d'arguments est lui-même implémenté comme un tableau d'octets côté hôte, mais ce détail interne ne doit pas être confondu avec le support d'un paramètre ou résultat public de type bytes.

Le constructeur générique d'arguments ne sérialise pas encore bytes, et l'exécuteur générique ne décode pas encore de résultat bytes.

Contrat sémantique public

Un buffer d'octets représente des données binaires opaques. L'ABI ne doit pas interpréter leur contenu comme du texte, déduire un encodage ni imposer un octet terminal.

Le contrat minimal utile est :

charge binaire = pointeur de données + longueur en octets + état null explicite

Le même concept physique de slice peut être partagé avec les chaînes UTF-8 ; c'est le type du descripteur qui indique si les octets doivent être interprétés comme du texte UTF-8 ou comme des données binaires opaques.

Buffers d'entrée

La première forme certifiée devrait être limitée à la durée de l'appel et appartenir à l'appelant :

tableau d'octets hôte
 -> stockage stable pendant l'appel
 -> vue binaire ABI
 -> invocation
 -> libération du stockage temporaire hôte

Le module ne doit pas conserver le pointeur après l'appel.

Buffers de résultat

La première forme certifiée devrait privilégier une sémantique copie puis libération :

le module alloue les octets résultat
 -> le module renseigne pointeur et longueur
 -> l'hôte copie les octets
 -> l'hôte appelle le free du module

Cette règle est volontairement plus stricte que l'exposition d'un pointeur natif brut. Elle rend le binding déterministe et maintient la responsabilité de l'allocateur à la frontière du module.

Limites et validations

Avant toute copie, l'hôte doit vérifier :

• que l'état null respecte la nullabilité du descripteur ;
• qu'une donnée non nulle possède une longueur cohérente ;
• que la longueur est représentable sans risque par le runtime hôte ;
• qu'une limite maximale de charge configurée n'est pas dépassée ;
• que les calculs de pointeurs ne peuvent pas déborder.

Un descripteur ABI décrit un layout et un ownership ; il ne donne pas un droit implicite à une allocation de taille illimitée.

Les tableaux constituent un autre contrat

Un buffer d'octets n'est pas l'ABI générique des tableaux. Un tableau doit aussi décrire le type des éléments, leur nombre, l'ownership imbriqué et éventuellement la libération de chaque élément. bytes doit donc être implémenté et certifié séparément avant le contrat plus général des tableaux.

Projection dans les bindings

Pour .NET, la projection par défaut devrait être une séquence managée comme byte[], ReadOnlyMemory<byte> ou un autre contrat généré adapté à la forme d'appel. L'API publique ne devrait pas imposer la manipulation directe du pointeur natif.

Critère de certification

Le type bytes pourra passer au statut reference lorsque les tests couvriront :

• entrée null, vide et non vide ;
• valeurs binaires contenant des octets nuls ;
• copie des résultats et libération moduleFree ;
• erreurs de dépassement de limite ;
• appels répétés sans fuite ;
• conversion FPL ;
• conversion du binding généré ;
• parité local/RPC lorsque la capacité est exposée à distance.