Ce ->> est-il un ancien opérateur ou une faute de frappe/erreur ?

Question

Au cours de mes lectures, je suis tombé sur WG14 Rapport de défaut n°51 écrit en 1993 (ou peut-être 1893, ils ont laissé de côté le siècle et le millénaire). Dans l'exemple de code là, apparemment un opérateur orthographié ->> est utilisé sur un pointeur vers un struct . Je ne le trouve pas dans les tableaux de précédence des opérateurs que j'ai trouvés, et je me demande donc s'il s'agit ou s'il s'agissait d'un opérateur, et si oui, que fait (ou faisait, selon le cas) cet opérateur ?

J'ai d'abord pensé qu'il s'agissait d'une faute de frappe, mais elle est reproduite deux autres fois dans le texte et une autre fois dans l'exemple de code de la réponse à la question, et j'ai du mal à croire qu'elle ait échappé à au moins deux experts en C sans être remarquée, alors qu'elle a sauté aux yeux d'un novice comme moi. Il se trouve également au point central du code, très facile à remarquer, et n'a jamais été corrigé.

Voici le code avec l'indentation ajoutée :

#include <stdlib.h>

struct A {
    char x[1];
};

main()
{
    struct A *p = (struct A *) malloc(sizeof(struct A) + 100);
    p->>x[5] = '?';  /* This is the key line [for both them and us] */
    return 0;
}

J'ai essayé de compiler ce code avec un compilateur C et C++ et il n'a pas été analysé dans les deux cas. Peut-être s'agissait-il d'un opérateur dans une ancienne version du C qui n'est plus utilisé ?

Cela ressemble étrangement à la Quel est le nom de cet opérateur : "-->" ? question, mais je ne pense pas qu'il s'agisse d'une combinaison de deux autres opérateurs, je ne vois pas comment on peut le diviser et être valide.

Answer 1

Cela ressemble à un problème dans le processus de transcription. Il y a un problème similaire dans le DR 42, où le signe plus grand que est doublé : http://www.open-std.org/jtc1/sc22/wg14/docs/rr/dr_042.html

Answer 2

J'ai appris le C en 1992, et je suis sûr à 100% que cet opérateur n'existait pas à l'époque.

Du contexte, p->>x[5] on peut en déduire qu'il semble faire exactement la même chose que l'opérateur flèche, plus familier, -> . Il s'agit donc probablement d'une erreur de frappe.

---

Il peut aussi s'agir d'un problème d'encodage lors de la transcription du code en HTML. Si vous regardez la source de cette page, vous pouvez voir qu'il y a un étrange mélange de codes d'échappement et de codes littéraux. < et > des personnages :

<TT><B>#include &lt;stdlib.h><BR>

Answer 3

Il semble probable qu'il s'agisse d'une erreur de transcription, mais je pense qu'il serait utile d'écrire comment un vrai compilateur C interpréterait cette construction, de toute façon, juste pour montrer qu'il ne s'agit pas d'une astuce. La première chose qu'il est important de savoir est cette phrase, tirée de C11 §6.5.4p4 (techniquement, N1570 ; ce langage est inchangé depuis C89, bien que le numéro de section soit probablement différent ; c'est moi qui souligne) :

Si le flux d'entrée a été analysé en jetons de prétraitement jusqu'à un caractère donné, le jeton de prétraitement suivant est le jeton de prétraitement le plus proche. prochain jeton de prétraitement est le le plus long séquence de caractères qui pourrait constituer un jeton de prétraitement.

Cela signifie que la chaîne de six caractères " p->>x" doit être considéré comme p -> > x pas p - >> x ou p - > > x . (Cela n'a pas vraiment d'importance dans ce cas, il s'agirait d'une erreur de syntaxe dans les deux cas, mais cette règle peut peut faire la différence entre un programme qui analyse comme prévu et un autre qui ne le fait pas ; la norme donne l'exemple suivant x+++++y qui est interprété comme x++ ++ +y pas comme x++ + ++y même si seule cette dernière est une expression bien formée).

La prochaine chose à savoir est simplement que l'argument de droite du -> doit être un identifiant selon les règles de grammaire de expression postfixe dans le §6.5.2. De toute évidence, > n'est pas un identifiant, nous avons donc une erreur de syntaxe certaine.