8
votes

Est-ce que la change f (muntruct * a) à F (const mystructeur * a) casse API / Abi en C?

1: void f(mystruct *a)
2: void f(const mystruct *a)
Does changing the function signature from 1->2 break API/ABI in C?
How about changing 2->1?

0 commentaires

5 Réponses :


2
votes

En ce qui concerne l'ABI est concerné, non, le const n'influence que les erreurs pendant la phase de compilation. Les fichiers d'objet compilés ne doivent avoir aucun reste de spécificateurs de const.


0 commentaires

3
votes

Cela dépend de ce que vous entendez par API. À l'heure de la compilée, un t * peut toujours être implicitement converti en un const t * ( note: outre l'exception que Jens Gustedt a souligné dans son Réponse! ). L'inverse n'est pas vrai; Un const t * ne sera pas converti implicitement en un t * , une distribution est donc toujours nécessaire pour éviter une erreur de compilateur. Donc, si vous modifiez la déclaration d'une fonction d'interface à partir de const à non- const , aucun de votre code client ne compilera. (Vous pouvez obtenir cela simplement en casissant le const de tous les appels, mais cela devrait être évité, sauf absolument inévitable, car le comportement n'est pas défini, et cela signifie que vous avez cassé votre propre contrat de l'interface).

Au niveau du bit (c'est-à-dire ABI), il n'y aura aucune différence entre les représentations de vos pointeurs ou d'objets. Cependant, cela ne veut pas dire que le compilateur n'aura pas effectué d'optimisation / d'hypothèses sur la base de quelque chose d'étant marqué const lors du code de machine généré les poignées de ces représentations; Si vous éliminez le const , ces hypothèses ne peuvent plus détenir et le code se cassera.


2 commentaires

Je suppose qu'il est logique que "il peut être implicitement converti à const t * " Bien qu'il semble un peu limitée car il est logique de faire fonctionner sur l'adresse du pointeur lui-même, c'est-à-dire dans pseudo et (* p)


@Dima, @Michael Burr: Non Il existe des situations où t * ne peut pas être converti en t const * . S'il vous plaît voir ma réponse.



5
votes

à partir de la norme C99 6.2.5 / 26 "Types":

Les pointeurs à des versions qualifiées ou non qualifiés de types compatibles doivent avoir les mêmes exigences de représentation et d'alignement.

de sorte que l'ABI / API ne doit pas être affecté de 1 à 2. (l'API ne change pas car un pointeur sur un type non qualifié non constitué peut être converti en un pointeur à une const- Version qualifiée du type - 6.3.2.3/2 "Conversions - Pointeurs").

Toutefois, si vous allez de 2 à 1, l'API change, car un pointeur sur un objet Const ne peut pas être converti implicitement à un pointeur sur un objet non-Const. Le code suivant compilerait sous la version 2, mais ne compilerait pas sous la version 1: xxx


0 commentaires

4
votes

autre que indiqué dans les deux réponses précédentes passant du 1-> 2 mai ou ne pas casser l'API. Cela dépend du type de base muntructeur code>. L'API briserait si autre que ce que le nom indique muntruct code> serait un typedef code> à un type de tableau.

mystruct A;
f(&A);


4 commentaires

+1: C'est intéressant. C'est un peu similaire à l'ancien A- Char ** -In-pas-pas- const Char ** règle, mais cela ne semble pas assez similaire. Qu'est-ce qui se passe ici?


@Oli, c'est parce que const (ou tout autre qualificatif) sur un type de tableau s'applique en réalité au type de base du tableau et non du type de matrice lui-même. Donc, dans un sens, un const une variante qualifiée d'un type de tableau n'existe pas. Pour Typedef Double Arr [1] Le type de Arr const est équivalent à double const [1] .


Oui, je suppose qu'il est logique que vous ne puissiez pas vraiment avoir un tableau const ! Mais quel scénario est le compilateur qui protège ici? Je ne peux pas voir un équivalent à C-FAQ.com/ansi/ConSmismatch.htmlled/a > Pour pointer-to-tableau.


@Oli, je pense que cela protège contre rien, c'est juste un artefact (défaut?) De la langue. Si vous êtes intéressé, je viens d'écrire quelque chose de plus tard une semaine environ concernant ceci: Gustedt.WordPress.com/2011/02/12/CONST-AND-Arrares



0
votes
error: passing argument 1 of ‘f’ discards qualifiers from pointer target type
note: expected ‘struct mystruct *’ but argument is of type ‘const struct mystruct *’

1 commentaires

Qu'est-ce que l'erreur du compilateur et pourquoi? compile bien ici à la fois ancienne et nouvelle dans l'un ou l'autre.