Que se passe-t-il si je définis un tableau de taille 0 en C / C ++?

Juste curieux, que se passe-t-il réellement si je définis un tableau de longueur nulle int array[0];dans le code? GCC ne se plaint pas du tout.

Exemple de programme

#include <stdio.h>

int main() {
    int arr[0];
    return 0;
}

Clarification

J'essaie en fait de déterminer si les tableaux de longueur nulle initialisés de cette façon, au lieu d'être pointés comme la longueur variable dans les commentaires de Darhazer, sont optimisés ou non.

C'est parce que je dois publier du code dans la nature, donc j'essaie de déterminer si je dois gérer les cas où le SIZEest défini comme 0, ce qui se produit dans un code avec une définition statiqueint array[SIZE];

J'ai été en fait surpris que GCC ne se plaint pas, ce qui a conduit à ma question. D'après les réponses que j'ai reçues, je pense que l'absence d'avertissement est en grande partie due au support de l'ancien code qui n'a pas été mis à jour avec la nouvelle syntaxe [].

Parce que je m'interrogeais principalement sur l'erreur, je marque la réponse de Lundin comme correcte (Nawaz était le premier, mais ce n'était pas aussi complet) - les autres soulignaient son utilisation réelle pour les structures rembourrées par la queue, bien que pertinente, n'est pas t exactement ce que je cherchais.

Un tableau ne peut pas avoir une taille nulle.

ISO 9899: 2011 6.7.6.2:

Si l'expression est une expression constante, elle doit avoir une valeur supérieure à zéro.

Le texte ci-dessus est vrai à la fois pour un tableau simple (paragraphe 1). Pour un VLA (variable length array), le comportement n'est pas défini si la valeur de l'expression est inférieure ou égale à zéro (paragraphe 5). Il s'agit d'un texte normatif dans le standard C. Un compilateur n'est pas autorisé à l'implémenter différemment.

gcc -std=c99 -pedantic donne un avertissement pour le cas non VLA.

Selon la norme, ce n'est pas autorisé.

Cependant, il est courant dans les compilateurs C de traiter ces déclarations comme une déclaration de membre de tableau flexible ( FAM ) :

C99 6.7.2.1, §16 : comme cas particulier, le dernier élément d'une structure avec plus d'un membre nommé peut avoir un type tableau incomplet; c'est ce qu'on appelle un membre de tableau flexible.

La syntaxe standard d'un FAM est:

struct Array {
  size_t size;
  int content[];
};

L'idée est que vous l'attribueriez alors ainsi:

void foo(size_t x) {
  Array* array = malloc(sizeof(size_t) + x * sizeof(int));

  array->size = x;
  for (size_t i = 0; i != x; ++i) {
    array->content[i] = 0;
  }
}

Vous pouvez également l'utiliser de manière statique (extension gcc):

Array a = { 3, { 1, 2, 3 } };

Ceci est également connu sous le nom de structures rembourrées en queue (ce terme est antérieur à la publication de la norme C99) ou de struct hack (merci à Joe Wreschnig de l'avoir signalé).

Cependant cette syntaxe n'a été normalisée (et les effets garantis) que récemment en C99. Avant, une taille constante était nécessaire.

• 1 était la voie portable à suivre, même si c'était plutôt étrange.
• 0 était meilleur pour indiquer l'intention, mais pas légal en ce qui concerne la norme et soutenu en tant qu'extension par certains compilateurs (y compris gcc).

Cependant, la pratique du rembourrage de la queue repose sur le fait que le stockage est disponible (prudent malloc) et n'est donc pas adapté à l'utilisation de la pile en général.

En C et C ++ standard, un tableau de taille nulle n'est pas autorisés.

Si vous utilisez GCC, compilez-le avec l' -pedanticoption. Il donnera un avertissement en disant:

zero.c:3:6: warning: ISO C forbids zero-size array 'a' [-pedantic]

Dans le cas de C ++, il donne un avertissement similaire.

C'est totalement illégal, et l'a toujours été, mais beaucoup de compilateurs négligent de signaler l'erreur. Je ne sais pas pourquoi vous voulez faire ça. La seule utilisation que je connais est de déclencher une erreur de compilation à partir d'un booléen:

char someCondition[ condition ];

Si conditionest un faux, alors j'obtiens une erreur de compilation. Parce que les compilateurs le permettent, cependant, j'ai commencé à utiliser:

char someCondition[ 2 * condition - 1 ];

Cela donne une taille de 1 ou -1, et je n'ai jamais trouvé de compilateur qui accepterait une taille de -1.

J'ajouterai qu'il y a une page entière de la documentation en ligne de gcc sur cet argument.

Quelques citations:

Les tableaux de longueur nulle sont autorisés dans GNU C.

Dans l'ISO C90, vous devrez donner au contenu une longueur de 1

et

Les versions de GCC antérieures à 3.0 permettaient d'initialiser statiquement les tableaux de longueur nulle, comme s'il s'agissait de tableaux flexibles. En plus des cas qui étaient utiles, il permettait également les initialisations dans des situations qui corrompraient les données ultérieures

pour que tu puisses

int arr[0] = { 1 };

et boum :-)

Une autre utilisation des tableaux de longueur nulle est de créer des objets de longueur variable (pré-C99). Tableaux de longueur zéro sont différents de réseaux flexibles qui ont [] sans 0.

Cité de gcc doc :

Les tableaux de longueur nulle sont autorisés dans GNU C. Ils sont très utiles comme dernier élément d'une structure qui est vraiment un en-tête pour un objet de longueur variable:

 struct line {
   int length;
   char contents[0];
 };
 
 struct line *thisline = (struct line *)
   malloc (sizeof (struct line) + this_length);
 thisline->length = this_length;

Dans ISO C99, vous utiliseriez un membre de tableau flexible, qui est légèrement différent en syntaxe et en sémantique:

• Les membres de tableau flexibles sont écrits en tant que contenus [] sans le 0.
• Les membres du tableau flexible ont un type incomplet, et donc l'opérateur sizeof peut ne pas être appliqué.

Un exemple concret est celui des tableaux de longueur nulle de struct kdbus_itemdans kdbus.h (un module du noyau Linux).

Les déclarations de tableau de taille zéro dans les structures seraient utiles si elles étaient autorisées, et si la sémantique était telle que (1) elles forceraient l'alignement mais n'alloueraient pas d'espace, et (2) l'indexation du tableau serait considérée comme un comportement défini dans le cas où le pointeur résultant serait dans le même bloc de mémoire que la structure. Un tel comportement n'a jamais été autorisé par aucun standard C, mais certains compilateurs plus anciens l'ont autorisé avant qu'il ne devienne standard pour les compilateurs d'autoriser les déclarations de tableau incomplètes avec des crochets vides.

Le piratage de structure, tel qu'il est généralement implémenté en utilisant un tableau de taille 1, est douteux et je ne pense pas qu'il soit nécessaire que les compilateurs s'abstiennent de le casser. Par exemple, je m'attendrais à ce que si un compilateur voit int a[1], il serait dans ses droits de considérer a[i]commea[0] . Si quelqu'un essaie de contourner les problèmes d'alignement du hack struct via quelque chose comme

typedef struct {
  taille uint32_t;
  données uint8_t [4]; // Utilisez quatre, pour éviter que le remplissage ne rejette la taille de la structure
}

un compilateur peut devenir intelligent et supposer que la taille du tableau est en réalité de quatre:

; Comme écrit
  toto = myStruct-> data [i];
; Telle qu'interprétée (en supposant un matériel petit-boutiste)
  toto = ((* (uint32_t *) monStruct-> données) >> (i << 3)) & 0xFF;

Une telle optimisation pourrait être raisonnable, surtout si elle myStruct->datapouvait être chargée dans un registre dans la même opération que myStruct->size. Je ne sais rien dans la norme qui interdirait une telle optimisation, même si bien sûr cela briserait tout code qui pourrait s'attendre à accéder à des éléments au-delà du quatrième élément.