summaryrefslogtreecommitdiff
path: root/articles/bizarreries-du-langage-c.md
blob: 45dc3946322e45ee9f81d77d30eef4ca30bc8518 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
---

pubDate = 2018-11-18
tags = ['C', 'bizarrerie', 'syntaxe', 'obfusquation', 'programmation']

[author]
name = "ache"
email = "ache@ache.one"

---



Les bizarreries du langage C
============================

![The C Programming Language logo](res/c_language.svg)  
Le C est un langage à la syntaxe simple. Les seules complexités de ce langage viennent du fait qu'il agit de manière proche de la machine.
Pourtant, une partie des syntaxes autorisées par le C n'est pratiquement jamais enseignée. Attaquons-nous à ces cas mystérieux ! 🧞

:::attention
Pour comprendre ce billet, il est nécessaire d'avoir des bases dans un langage ayant une syntaxe et un fonctionnement proche du C.
:::


Sommaire
--------


Les opérateurs inusités
----------------------

Il existe deux opérateurs dans le langage C qui ne sont pratiquement jamais utilisés. Le premier est l'opérateur virgule.
En C la virgule sert à séparer factoriser les éléments d'une définition ou séparer les éléments d'une fonction. En bref, c'est un élément de ponctuation.
Mais pas seulement ! C'est également un opérateur.


### L'opérateur virgule

L'instruction suivante, bien qu'inutile est tout à fait valide :

~~~c
printf("%d", (5,3) );
~~~

Elle affiche 3. L'opérateur `,` sert à juxtaposer des expressions.
La valeur de l'expression complète est égale à la valeur de la dernière expression.

Cet opérateur se révèle très utile dans une boucle `for` pour multiplier les itérations.
Par exemple pour incrémenter `i` et décrémenter `j` dans la même itération d'une boucle `for` on peut faire :
~~~c
for( ; i < j ; i++, j-- ) {
 // [...]
}
~~~

Ou encore, dans de petits `if` pour les simplifier :

~~~c
if( argc > 2 && argv[2][0] == '0' )
    action = 4, color = false;
~~~

Ici, on assigne `action` et `color`. Normalement pour faire 2 assignations, on aurait dû mettre des accolades au `if`.

On peut également s'en servir pour retirer des parenthèses.

~~~c
while( c = getchar(), c != EOF && c != '\n' ) {
  // [...]
}
// Est strictement équivalent à :
while( (c = getchar()) != EOF && c != '\n' ) {
  // [...]
}
~~~

Mais surtout, ne pas abuser de cet opérateur ! On peut, de manière assez rapide, obtenir des choses illisibles.
Cette remarque est d'ailleurs également valide pour le prochain opérateur !

### L'opérateur ternaire

Le ternaire pour les intimes. Le seul opérateur du langage C qui prenne 3 opérandes.
Il sert à simplifier des expressions conditionnelles.

Par exemple pour afficher le minimum de deux nombres, sans le ternaire, on ferait :

~~~c
if (a < b)
    printf("%d", a);
else
    printf("%d", b);
~~~

Ou avec une variable temporaire :

~~~c
int min = a;
if( b < a)
  min = b;
printf("%d", min);
~~~

Alors qu'avec les ternaires on fait simplement :

~~~c
printf("%d", a<b ? a : b);
~~~

Grâce au ternaire, on a économisé une répétition ainsi que quelques lignes.
Mais surtout on a gagné en lisibilité. Quand on sait en lire une...

Pour lire une expression ternaire, il faut la découper en 3 parties :

~~~c
expression_1 ? expression_2 : expression_3
~~~

La valeur d'une expression ternaire est `expression_2` si la valeur de `expression_1` est évaluée à vrai et `expression_3` sinon.

En somme, cela simplifie un peu la lecture pour de courtes expressions.
L'expression `a<b ? a : b` se lit « Si `a` est inférieur à `b` alors `a` sinon `b` ».

J'insiste encore sur le fait que cet opérateur, s'il est mal utilisé, peut nuire à la lisibilité du code.
Notez que l'on peut très bien utiliser une expression ternaire comme opérande d'une autre expression ternaire :

~~~c
printf("%d", a<b ? a<c ? a : b<c ? b : c : b < c ? b : c); 
~~~

Désormais, on prend le minimum de trois nombres. C'est aéré, mais impossible à suivre.
Le plus lisible est d'utiliser une macro :

~~~c
#define MIN(a,b) ((a) < (b) ? (a) : (b))

printf("%d", MIN(a,MIN(b,c)));
~~~

Et voilà ! Deux opérateurs qui vont désormais gagner un peu d'intérêt.
Et être mieux compris !
Puis d'ailleurs, même les opérateurs que l'on connait déjà, on n'en maîtrise pas forcément la syntaxe.

L'accès à un tableau
------------------

On nous a toujours appris que pour afficher le 3ème élément d'un tableau, on faisait :

~~~c
int tab[5] = {0, 1, 2, 3, 4, 5};
printf("%d", tab[2]);
~~~

2 et non 3, car un tableau en C commence à 0. Si un tableau commence à 0, c'est une histoire d'adresse[^adresse]. L'adresse du tableau est en fait l'adresse du premier élément du tableau. Et par arithmétique des pointeurs, l'adresse du 3ème élément est `tab+2`.

Donc on aurait très bien pu écrire :

~~~c
printf("%d", *(tab+2));
~~~

Puis comme l'addition est commutative, `tab+2` ou `2+tab` sont équivalents.
En fait, on aurait même pu faire :

~~~c
printf("%d", 2[tab]);
~~~

C'est tout à fait valide. Et pour cause : la syntaxe `E[F]` est strictement équivalente à `*((E)+(F))`.
Du coup, le titre de cette section est un peu trompeur. Cet opérateur n'a pas grand-chose à voir avec les tableaux en fait. 
C'est du sucre syntaxique pour cacher l'arithmétique des pointeurs.[^sucre]

Par exemple pour afficher le caractère `=` pour vrai, `!` pour faux et `~` pour aucun des deux.
On pourrait faire :
~~~c
if( is_good == 1 )
  printf("%c", '=');
else if( is_good == 0 )
  printf("%c", '!');
else
  printf("%c", '~');
~~~

Mais il existe plus simple :
~~~c
printf("%c", "!=~"[is_good]);

// Ou comme on l'a vu :
printf("%c", is_good["!=~"] ); // Affiche '!' si is_good vaut 0
                               //         '=' si is_good vaut 1
                               //         '~' si is_good vaut 2
~~~

En somme, tout le monde écrit `tab[3]` et pas `3[tab]`. Du coup, il n'y a aucun intérêt à écrire `3[tab]`.
Mais c'est toujours bon de savoir que ça existe. ^^

[^adresse]: C'est un peu plus compliqué que cela. À l'époque où il a fallu choisir si on commençait un tableau à l'indice 0 ou 1, le temps de compilation d'un programme avait une importance particulière. Il a été décidé de commencer à 0 afin de ne pas perdre de temps à la compilation en translation d'indices. L'article [Citation Needed](http://exple.tive.org/blarg/2013/10/22/citation-needed/) de Mike Hoye explique cela bien mieux que moi.

[^sucre]: Pour la petite histoire l'opérateur `[]` est hérité du langage B où le concept de tableau n'existait pas comme en C. Un tableau (ou vecteur comme on l'appelait à l'époque) n'était que l'adresse du premier élément d'une suite d'octets. Seul l'arithmétique des pointeurs permettait d'accéder à tous les éléments d'un tableau, c'est une évolution comparé au BCPL, l'ancêtre du B, qui utilisait la syntaxe `V!4` pour accéder au cinquième élément d'un tableau, mais je m'égare...

L'initialisation
---------------

L'initialisation, c'est quelque chose que l'on maîtrise en C. C'est le fait de donner une valeur à une variable lors de sa déclaration.
En gros, on définit sa valeur.

Pour un tableau[^tableau] :
~~~c
int tab[10] = {0};
tab[2] = 5;
~~~


À la première ligne, on initialise le tableau avec des 0 car, lorsqu'on initialise un tableau toute valeur non spécifiée est par défaut 0.
La ligne suivante est une affectation et non une initialisation.

Si on veut seulement initialiser le troisième élément, puisque l'initialisation d'un tableau se fait suivant l'ordre de ses valeurs, on devrait écrire :

~~~c
int tab[10] = {0, 0, 5};
~~~

Mais en réalité, il existe une autre syntaxe qui permet de faire plus simple :

~~~c
int tab[10] = {[2] = 5};
~~~

On dit simplement que la troisième case vaut 5. Le reste est par défaut 0.
Une syntaxe équivalente existe d'ailleurs pour les structures et les unions.

:::information
 Pour l'exemple, on va prendre une structure `point` que je vais utiliser plusieurs fois dans ce billet, idem pour la structure `message`.
:::

On peut ainsi initialiser un point en utilisant ses composantes.

~~~c
typedef struct point {
  int x,y;
} point;


point A = {.x = 1, .y = 2};
~~~

Ici, il n'y avait pas d'ambigüité.
Mais pour une structure plus complexe, cette syntaxe est vraiment avantageuse.

Tenez :

~~~c
typedef struct message {
   char src[20], dst[20], msg[200];
} message;

// [...]

message to_send = {.src="", .dst="23:12:23", .msg="Code 10"};

// Est bien plus clair que :

message to_send = {"", "23:12:23", "Code 10"};

// D'ailleurs, je ne l'ai pas fait mais avec cette syntaxe pas besoin de se souvenir de l'ordre
// des champs de la structure

message to_send = { .msg="Code 10", .dst="23:12:23", .src=""};

// Et aussi puisque tout champ d'une structure est inialisé à sa valeur nulle s'il n'est pas initialisé explicitement.
// On peut également omettre src.

message to_send = { .dst="23:12:23", .msg="Code 10"};
~~~


Avec ces syntaxes on peut également alourdir le code, mais généralement, on gagne en lisibilité.
Parfois, ces syntaxes sont très judicieusement utilisées !
Comme ici, dans ce décodeur de base64 :
>~~~c
>static int b64_d[] = {
>    ['A'] =  0, ['B'] =  1, ['C'] =  2, ['D'] =  3, ['E'] =  4,
>    ['F'] =  5, ['G'] =  6, ['H'] =  7, ['I'] =  8, ['J'] =  9,
>    ['K'] = 10, ['L'] = 11, ['M'] = 12, ['N'] = 13, ['O'] = 14,
>    ['P'] = 15, ['Q'] = 16, ['R'] = 17, ['S'] = 18, ['T'] = 19,
>    ['U'] = 20, ['V'] = 21, ['W'] = 22, ['X'] = 23, ['Y'] = 24,
>    ['Z'] = 25, ['a'] = 26, ['b'] = 27, ['c'] = 28, ['d'] = 29,
>    ['e'] = 30, ['f'] = 31, ['g'] = 32, ['h'] = 33, ['i'] = 34,
>    ['j'] = 35, ['k'] = 36, ['l'] = 37, ['m'] = 38, ['n'] = 39,
>    ['o'] = 40, ['p'] = 41, ['q'] = 42, ['r'] = 43, ['s'] = 44,
>    ['t'] = 45, ['u'] = 46, ['v'] = 47, ['w'] = 48, ['x'] = 49,
>    ['y'] = 50, ['z'] = 51, ['0'] = 52, ['1'] = 53, ['2'] = 54,
>    ['3'] = 55, ['4'] = 56, ['5'] = 57, ['6'] = 58, ['7'] = 59,
>    ['8'] = 60, ['9'] = 61, ['+'] = 62, ['/'] = 63, ['='] = 64
>};
>~~~
Source: [Taurre](https://openclassrooms.com/forum/sujet/defis-8-tout-en-base64-19054?page=1#message-6921633)


[^tableau]:
    `{0}` peut également être utilisé pour un nombre. Toute valeur initialisant une variable simple (pointeur, nombre, ...) peut optionnellement prendre des accolades.

    ~~~c
    int a = {11};
    float pi = {3.1415926};
    char* s = {"unicorn"};
    ~~~

    Ce qui caractérise le tableau du coup est surtout le fait d'utiliser des virgules entre les accolades.

Les expressions littéralement composées
--------------------------------------

Puisque nous parlons des tableaux. Il existe une syntaxe simple pour utiliser des tableaux à usage unique.

Je voudrais utiliser ce tableau :
~~~c
int tab[5] = {5, 4, 5, 2, 1};
printf("%d", tab[i]); // Avec i égale à quelque chose >=0 et <5
~~~

Cependant, je ne l'utilise qu'une seule fois ce tableau ...
C'est un peu dérangeant d'avoir à utiliser un identificateur juste pour ça.

*Eh* bien je peux faire ceci :
~~~c
printf("%d", ((int[]){5,4,5,2,1}) [i] ); // Avec i égale à quelque chose >=0 et <5
~~~

Ce n'est pas super lisible pour le coup. Mais il existe plein de cas où cette syntaxe est très utile. Par exemple avec une structure :

~~~c

// Pour envoyer notre message :
send_msg( (message){ .dst="192.168.11.1", .msg="Code 11"} );

// Pour afficher la distance entre deux points
printf("%d", distance( (point){1, 2}, (point){2, 3} )  );

// Ou encore sous Linux, en programmation système
execvp( "bash" , (char*[]){"bash", "-c", "ls", NULL} );
~~~

On appelle ces expressions des *compound literals* (ou littéraux agrégats si l'on s'essaye à traduire).

Introduction aux VLAs
--------

Les tableaux à taille variable (ou *Variable Length Arrays* en anglais, soit VLAs) sont des tableaux dont la taille n'est connue qu'à l'exécution. Si vous n'avez jamais entendu parler des VLAs, ceci devrait vous choquer :

~~~c
int n = 11;

int tab[n];

for(int i = 0 ; i < n ; i++)
  tab[i] = 0;
~~~

Ce code, bien que valide, a dû être réprimandé par de nombreux professeurs. En effet, on nous apprend qu'un tableau doit avoir une taille connue à la compilation.
*Eh* bien, les VLAs constituent l'exception. Apparu avec la norme C99, les VLAs jouissent d'une mauvaise réputation. À cela, il existe plusieurs raisons que je ne détaillerais pas ici[^raisons]. Je vais simplement parler des comportements non-intuitifs introduits avec les VLAs. Mais tout d'abord, voyons ce qu'est et comment se servir d'un tableau à taille variable.

Les VLAs se définissent avec la même syntaxe qu'un tableau classique. La seule différence est que la taille du tableau est une expression entière non constante.

~~~c
int n = 50;
int tab[n];

double tab2[2*n];

unsigned int tab[foo()]; // avec foo une fonction définie ailleurs
~~~

Un VLA ne peut pas être initialisé, de plus, il ne peut être déclaré `static`. C'est-à-dire que ces deux déclarations sont incorrectes :

~~~c
int n = 30;

int tab[n] = {0};
static tab2[n];
~~~

Dans une fonction, on pourrait utiliser :

~~~c
void bar(int n, int tab[n]) {

}
~~~

Cependant, la taille de la première dimension d'un tableau n'a pas beaucoup d'importance, un tableau étant implicitement convertit en un pointeur vers son premier élément. En revanche, pour un tableau à deux dimensions, la taille de la deuxième dimension *doit* être spécifiée :

~~~c
void foo( int n, int m, int tab[][m]) {

}
~~~

À noter qu'il est possible d'utiliser le caractère `*` (encore une utilisation de plus) en lieu et place de la taille d'une ou plusieurs dimensions d'un VLA, mais *uniquement* au sein d'un prototype.

~~~c
void foo(int, int, int[][*]);
~~~

Bien, après cette courte introduction aux VLAs, passons aux cas qui nous intéressent. Pour être précis, les bizarreries et excentricités que les VLAs ont introduits.

[^raisons]: Je peux néanmoins vous donnez deux références [“Is it safe to use variable-length arrays?”](https://stackoverflow.com/questions/7326547/is-it-safe-to-use-variable-length-arrays) de stack overflow et cet article : [“The Linux Kernel Is Now VLA-Free”](https://www.phoronix.com/scan.php?page=news_item&px=Linux-Kills-The-VLA).

L'exception des VLAs
---------------------------

Le comportement déviant le plus connu des VLAs est leur rapport à `sizeof`.

`sizeof` est un opérateur unaire qui permet de retrouver la taille d'un type à partir d'une expression ou du nom d'un type entouré de parenthèses. 

~~~c
/*  Le fonctionnement de l'opérateur sizeof par des exemples */ 
float a;
size_t b = 0;

printf("%zu", sizeof(char)); // Affiche 1
printf("%zu", sizeof(int));  // Affiche 4
printf("%zu", sizeof a);     // Affiche 4
printf("%zu", sizeof(a*2.)); // Affiche 8
printf("%zu", sizeof b++);   // Affiche 8
~~~

Le premier résultat n'est pas très surprenant, la taille d'un `char` est défini à 1 *byte* et `sizeof(char)` doit retourner 1. Le deuxième résultat est la taille d'un `int`[^machine]. Le troisième résultat est la taille d'un `float`[^machine]. Le quatrième est la taille d'un `double`[^machine] qui est le type de l'expression `a*2.`[^float]. Le dernier résultat est la taille d'un `size_t`[^machine], `size_t` étant le type de l'expression `b++`.

Ici, je ne me suis pas intéressé à la valeur des expressions et pour cause, `sizeof` ne s'y intéresse pas non plus. Ces valeurs sont déterminées à la compilation. Les opérations que l'on retrouve dans l'expression passé à `sizeof` ne sont pas effectuées. Puisque l'expression doit être valide, son type doit être déterminé à la compilation. Le résultat de `sizeof` étant alors connu à la compilation, il n'y avait aucune raison d'exécuter l'expression.

~~~c
int n = 5;
printf("%zu", sizeof(char[++n])); // Affiche 6
~~~

*Arf* ! Les VLAs rajoutent leur grain de sel. Dans le type `int[++n]`, `++n` est une expression non constante. Donc le tableau est un tableau à taille variable. Pour connaitre la taille totale du tableau, il est nécessaire d'exécuter l'expression entre crochet. Ainsi `n` vaut désormais 6 et `sizeof` nous indique qu'un VLA de `char` déclaré avec cette expression aurait eu pour taille `6`.

Ce n'est que peu intuitif puisque les VLAs ont ici introduit une *exception à la règle* qui est de ne pas exécuter l'expression passée à `sizeof`.


Un autre comportement bizarre introduit par les VLAs est l'exécution des expressions liées à la taille d'un VLA dans la définition d'une fonction. Ainsi :

~~~c
int foo( char tab[printf("bar")] ) {
   printf("%zu", sizeof tab);
}
~~~

En supposant que les affichages ne causent pas d'erreur, appeler cette fonction affichera `bar3`. L'instruction `printf("bar")` est évaluée et ensuite seulement le corps de la fonction est exécuté.

Il est à noter qu'il existe d'autres exceptions induites pas la standardisation des VLAs comme l'impossibilité d'allouer les VLAs de manière statique (assez logique), ou l'impossibilité d'utiliser des VLAs dans une structure (GNU GCC le support tout de même). Et même certains branchements conditionnels sont interdits lorsque l'on utilise un VLA.

[^machine]: Sur ma machine
[^float]: Ici, l'implémentation des nombres flottants suit la norme IEE 754, où la taille d'un nombre flottant simple est de 4 octets et double précision est de 8 octets. `2.` est de type `double`, l'expression `2.*a` est donc du même type que le plus grand des deux types de ses deux opérandes, ici `double`.

Un tableau flexible
-------------------

Vous n'avez peut-être jamais entendu parler des « *flexible arrays member* ». C'est normal, ceux-ci répondent à une problématique très précise et peu courante.

L'objectif est d'allouer une structure mais dont un champ (un tableau) est de taille inconnue à la compilation et le tout sur un espace contiguë[^pourquoi].

Ici, pas de VLAs, car comme on l'a vu, ceux-ci sont interdits en tant que champs de structure. L'allocation dynamique s'impose.  
On pourrait vouloir faire :

~~~c
struct foo {
  int* tab;
};
~~~

Et l'utiliser comme ceci :

~~~c
  struct foo* contigue = malloc( sizeof(struct foo) );
  if (contigue) {
    contigue->tab = malloc( N * sizeof *contigue->tab );
    if (contigue->tab) {
      contigue->tab[0] = 11;
    }
  }
~~~

Mais ici, le tableau n'a aucune raison d'être contiguë à la structure. Ce qui aura pour conséquence qu'en cas de copie de la structure, la valeur du champ `tab` sera la même pour la copie et l'origine. Pour éviter cela, il faudra copier la structure, réallouer le tableau et le recopier. Voyons une autre méthode.

~~~c
struct foo {
  /* ... Au moins un autre champ car le standard l'impose. */
  int flexiTab[];
};
~~~

Ici, le champ `flexiTab` est un tableau membre flexible. Un tel tableau doit être le dernier élément de la structure et ne pas spécifier de taille[^zero]. On l'utilise comme ceci :

~~~c
  struct foo* contigue = malloc( sizeof(struct foo) + N * sizeof *flexiTab );
  if (contigue) {
    flexiTab[0] = 11;
  }
~~~

Cette syntaxe répond autant à un besoin de portabilité sur les architectures imposant un alignement particulier (le tableau est contigu à la structure) qu'au besoin de faire apparaître un lien sémantique entre le tableau et la structure (le tableau appartient à la structure).


[^pourquoi]: On peut vouloir que cet espace soit contiguë pour plusieurs raisons. Une de ces raisons est pour optimiser l'utilisation du cache processeur. Également, la gestion des couches réseaux se portent assez bien à l'utilisation de tableaux flexibles.
[^zero]: Avant la spécification des « flexible array member » en C99, il était courant d'utiliser des tableaux de taille un pour reproduire le concept.


Une histoire d'étiquettes
------------------------

En C, s'il y a un truc dont on ne doit pas parler, ce sont bien des *étiquettes*.
On les utilise avec la structure de contrôle `goto` ! L'interdite !

Pour les cacher, on remplace les `goto` par des structures de contrôles adaptées et plus claires comme `break` ou `continue`.
De manière à ne jamais avoir à utiliser `goto`.

Du coup, on n'apprend jamais ce qu'est une étiquette...

Voici comment on utilise `goto` et une étiquette :

~~~c
goto end;


end: return 0;
}
~~~
En gros, une étiquette est un nom que l'on donne à une instruction.


*Eh* bien on en utilise des étiquettes ! Dans les `switch` !

~~~c

switch( action ) {
    case 0:
        do_action0();
    case 1:
        do_action1();
        break;
    case 2:
        do_action2();
    break;
    default:
        do_action3();
}
~~~

Ici, les `case` et le `default` sont en fait des étiquettes ! Comme pour les `goto`.
Sauf qu'elles sont pour les `switch`, et inutilisables par les `goto`...


:::question
Pourquoi tu nous parles de ça ?
:::

Déjà, c'est bien de savoir que ça s'appelle une étiquette. Ensuite, parce que je vais vous parlez d'un classique.
Le dispositif de *Duff*.

C'est une sorte de boucle déroulée optimisée. Le but est de réduire le nombre de vérifications de fin de boucle (ainsi que le nombre de décrémentations).

Voici la version historique écrite par Tom Duff :

~~~c
{
    register n = (count + 7) / 8;
    switch (count % 8) {
    case 0: do { *to = *from++;
    case 7:      *to = *from++;
    case 6:      *to = *from++;
    case 5:      *to = *from++;
    case 4:      *to = *from++;
    case 3:      *to = *from++;
    case 2:      *to = *from++;
    case 1:      *to = *from++;
            } while (--n > 0);
    }
}
~~~

Peu importe ce que signifie `register`. Aussi, `to` est un pointeur particulier, mais ce n'est pas vraiment important.

Ici, ce dont je veux vous parler, c'est de cette boucle `do-while` en plein milieu d'un `switch`.

Le test que l'on cherche à effectuer le moins possible est `--n > 0`.

En temps normal, `n` serait en fait `count`. Et on devrait faire le test `count` fois.
De même pour sa décrémentation.

C'est-à-dire :

~~~c
while( count-- > 0 )
    *to = *from++;
~~~

En divisant par 8 (nombre arbitraire) on divise également par 8 le nombre de tests et de décrémentations.
Cependant, si `count` n'est pas divisible par 8, on a un problème, on ne fait pas toutes les instructions.
Ce serait bien de pouvoir sauter directement à la 2ème instruction, si on a seulement 6 instructions restantes.

Et c'est là que les étiquettes peuvent nous aider !
Grâce au `switch` on peut sauter directement à la bonne instruction.

Il suffit d'étiqueter chaque instruction avec le nombre d'instructions qu'il reste à faire dans la boucle.
Puis de sauter dans la boucle avec la structure de contrôle `switch` sur le reste d'instructions à réaliser.

Ensuite, on exécute nos paquets de 8 instructions normalement.

Il est très rare d'avoir à utiliser ce type d'astuce.
D'ailleurs, c'est une optimisation d'un autre temps.
Mais comme je voulais vous parler de syntaxe, il était nécessaire de parler des étiquettes.

Les nombres complexes
--------------------

Encore une fois nous allons voir une syntaxe introduite en C99. Plus exactement, ce sont 3 types qui ont été introduits, ceux-ci correspondent aux nombres complexes. Le type d'un nombre complexe est `double _Complex` (les deux autres types suivent le même schéma, afin de ne pas me répéter, je vais me concentrer sur le type `double`).

Ainsi en C, il est possible de déclarer un nombre complexe comme ceci :

~~~c
double complex point = 2 + 3 * I;
~~~

Ici, on retrouve les macros spéciales `complex` et `I` (définie dans l'en-tête `<complex.h>`). Le premier sert à créer un type complexe alors que le second sert à définir la partie imaginaire d'un nombre complexe.

En mémoire une variable complexe occupe autant d'espace que 2 fois le type réel sur lequel elle est basée. On se sert d'une variable complexe comme d'une variable normale. L'arithmétique y est intuitive puisque basées sur celle des réels. Il est à noter qu'il est recommandé d'utiliser le macro `CMPLX` pour initialiser un nombre complexe :

~~~c
double complex cplx = CMPLX(2, 3);
~~~

Pour une meilleure gestion des cas où la partie imaginaire (celle multipliée par `I` donc) serait `NAN`, `INFINITY` ou encore plus ou moins 0.

L'en-tête `<complex.h>` nous offre une manière réellement simple d'utiliser des nombres imaginaires. En effet, de nombreuses fonctions courantes de manipulations des nombres imaginaires y sont disponibles.

Les macros génériques
---------------------

Il existe un moyen en C d'avoir des macros qui soient définies différemment en fonction du type de l'un de ses arguments. Cette syntaxe est cependant « nouvelle » puisqu'elle date du standard C11.

Cette généricité s'obtient avec les sélections génériques basées sur la syntaxe ` _Generic ( /* ... */ )`

Pour comprendre la syntaxe, voyons un exemple simpliste :

~~~c
#include <stdio.h>
#include <limits.h>

#define MAXIMUM_OF(x) _Generic ((x), \
                                char: CHAR_MAX, \
                                int:  INT_MAX,  \
                                long: LONG_MAX  \
                                )

int main(int argc, char* argv[]) {
    int i = 0;
    long l = 0;
    char c = 0;

    printf("%i\n", MAXIMUM_OF(i));
    printf("%d\n", MAXIMUM_OF(c));
    printf("%ld\n", MAXIMUM_OF(l));
    return 0;
}
~~~

Ici, on affiche le maximum que peut stocker chacun des types que nous utilisons. C'est quelque chose qui n'aurait pas été possible sans l'utilisation de ce nouveau mot-clé `_Generic`.
Pour utiliser cette syntaxe, on utilise le mot clé `_Generic` auquel on passe 2 paramètres. Le premier est une expression dont le type va influencer l'expression finalement exécutée. Le deuxième est une suite d'association de type et d'expression (type : expression) dont les associations sont séparées par des virgules. Au final, seule l'expression désignée par le type de la première expression est finalement évaluée.


Un exemple réel d'utilisation pourrait être :
~~~c
int powInt(int,int);

#define POW(x,y) _Generic ((y), double: pow, float: powf, long double: powl, int: powInt)((x), (y))
~~~


Il n'y a plus grand-chose à dire si ce n'est qu'il est possible d'avoir dans la liste des types le mot `default` qui correspondra alors à tous les types non-cités. Ainsi une définition plus propre de la macro `POW` de tout à l'heure pourrait être :

~~~c
int powIntuInt(int a, unsigned int b);
double powIntInt(int a, int b);
double powFltInt(double a,int b) { return pow (a,b); }
double powfFltInt(float a,int b) { return powf(a,b); }
double powlFltInt(long double a,int b) { return powl(a,b); }


#define POWINT(x) _Generic((x), double: powFltInt,          \
                                float : powfFltInt,         \
                                long double: powlFltInt,    \
                                unsigned int: powIntuInt,   \
                                default: powIntInt)
#define POW(x,y) _Generic ((y), double: pow, float: powf, long double: powl, default: POWINT((x)) )((x), (y))
~~~

Les caractères trop spéciaux
---------------------------


On va remonter encore dans le temps.
Je vais vous citer une dernière chose.
Un temps où tous les caractères n'étaient pas aussi accessibles que de nos jours sur autant de types de claviers.

Les claviers n'avaient pas forcément de touches de composition. Ainsi, il était impossible de taper le caractère `#`.

On pouvait alors remplacer le caractère `#` par la séquence `??=`. 
Et pour chaque caractère n'étant pas sur le clavier et utiliser en langage C, il existait une séquence à base de `??` que l'on nomme trigraphe. Une autre version à base de 2 caractères plus lisible se nomme les digraphes.

Voici un tableau récapitulatif des séquences de trigraphes, de digraphes et de leur représentation en caractère. 

| Caractère | Digraphe | Trigraphe |
| --------- | -------- | --------- |
|     `#`   |     `%:` |     `??=` |
|     `[`   |     `<:` |     `??(` |
|     `]`   |     `:>` |     `??)` |
|     `{`   |     `<%` |     `??<` |
|     `}`   |     `%>` |     `??>` |
|     `\`   |          |     `??/` |
|     `^`   |          |     `??'` |
|     `\|`  |          |     `??!` |
|     `~`   |          |     `??-` |
|     `##`  |   `%:%:` |           |



La différence **principale** entre les digraphes et les trigraphes est dans une chaîne de caractère :

~~~c
puts("??= est un croisillon");
puts("%:");
~~~

Ces mécanismes du Moyen Âge sont encore valides de nos jours en C.
Du coup, cette ligne de code est tout à fait valide :
~~~c
??=define FIRST tab<:0]
~~~

La seule utilité de cette syntaxe de nos jours est d'obfusquer un code source très facilement.
Une combinaison d'un ternaire avec un trigraphe et un digraphe et vous avez un code absolument illisible. ;)

~~~c
printf("%d", a ?5??((tab):>:0);
~~~

**À ne jamais utiliser dans un code sérieux** donc.


## Conclusion

Voilà, c'est fini, j'espère que vous avez appris quelque chose de ce billet. Surtout n'oubliez pas d'utiliser ces syntaxes avec parcimonie.

Je tiens tout particulièrement à remercier [Taurre](https://zestedesavoir.com/membres/voir/Taurre/) pour avoir validé cet article, mais également pour sa pédagogie sur les forums depuis des années, ainsi que [blo yhg](https://zestedesavoir.com/membres/voir/blo%20yhg/) pour sa relecture attentive.

À noter que vous pouvez (re)découvrir de nombreux codes abusant de la syntaxe du langage C aux [IOCCC](http://ioccc.org/winners.html). 😈