Discussion :

[picodev]

Je pense qu'Obsidian voulait pointer le fait que cette relation n'est pas forcément vraie suivant l'endianness de la machine.

[BufferBob]

ah oui évidemment ça, on peut pas tout avoir mais dans le contexte (exo epitruc, prête peu à conséquence...) je me suis dit que ça pouvait peut-être aider, mais c'est clair que c'est hackish et endian-dependant
reste que je vois toujours pas l'intérêt, si il utilise la lib curses les keycodes doivent déjà être définis et avoir leur petit nom comme KEY_UP et autres

[Obsidian]

Je pense qu'Obsidian voulait pointer le fait que cette relation n'est pas forcément vraie suivant l'endianness de la machine.

En fait, on a effectivement remarqué le soin que BufferBob a pris à tenir compte de l'endianess et c'est saluable. Le problème est ailleurs…

ben... j'aurais tendance à dire que oui, en tous cas du point de vue finalité/code machine, du point de vue langage C à voir, mais tu me fous le doute d'un coup

En fait, la première et la troisième version définissent bien un tableau de caractère, lequel est initialisé (et donc rempli en mémoire) avec les valeurs spécifiée. La deuxième version, elle, définit un pointeur pointant l'adresse « 0x00b8e0f6 », spécifiée comme un entier et explicitement castée en « (char *) » pour pouvoir être affectée au pointeur. Utiliser ce pointeur va donc nous renvoyer n'importe où en mémoire et provoquer une segfault. Pour que ça marche quand même, il aurait fallu que le pointeur se pointe lui-même.

Voici un petit programme qui met cela en évidence et où la ligne incriminée est en troisième position :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <stdint.h>
#include <stdio.h>
 
int main (void)
{
    char  s1[]  = {-10,-32,-72,0};
    char  s2[]  = "\xf6\xe0\xb8\x00";
    char *s3    = (char *)0x00b8e0f6;
 
    printf ("s1=%p &s1=%p\n",s1,&s1);
    printf ("s2=%p &s2=%p\n",s2,&s2);
    printf ("s3=%p &s3=%p\n",s3,&s3);
 
    puts("");
 
    printf ("*s1 = %x\n",*(intptr_t *)s1);
    printf ("*s2 = %x\n",*(intptr_t *)s2);
    printf ("*s3 = %x\n",*(intptr_t *)s3);
 
    return 0;
}

Code shell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$ ./programme
s1=0x7ffd295b8c80 &s1=0x7ffd295b8c80
s2=0x7ffd295b8c70 &s2=0x7ffd295b8c70
s3=0xb8e0f6 &s3=0x7ffd295b8c68

*s1 = b8e0f6
*s2 = b8e0f6
Erreur de segmentation (core dumped)

[Médinoc]

Au passage, attention pour les nombres négatifs, strictement du point de vue de la norme C le complément à deux n'est pas garanti (la valeur "minimale" de INT_MIN selon la norme est -INT_MAX et non pas le -INT_MAX-1 que la plupart des implémentations offrent).

Mais pour le sujet initial, je ne vois toujours pas l'intérêt de telles manipulations:

• soit termcap fonctionne comme getchar(), et ne peut retourner que des valeurs unsigned char ou -1 pour Erreur, auquel cas inutile de jouer avec des valeurs négatives;
• soit termcap() peut retourner des vraies valeurs négatives, auquel cas il faut utiliser des int, pas des char.

De plus, une table de déclaration de correspondance caractère -> fonction est constante et n'a rien à faire en variable locale à une fonction: Il s'agit de données constantes, autrement dit une variable globale const, qui ne doit pas être contrainte par les limites de taille des fonctions:

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
static int fonction1(void) { return 0; }
static int fonction2(void) { return 0; }
static int fonction3(void) { return 0; }
struct charFunc { char c; int (*func)(void); };
 
struct charFunc const g_funcs[] = {
	{ '1', fonction1 },
	{ '2', fonction2 },
	{ '3', fonction3 },
	{ '\0', NULL }
};