Discussion :

[ternel]

En fait, en théorie, char admet des valeurs dans [0..127] (au minimum), et représente des caractères, tandis que signed char (au moins [-128..127]) et unsigned char (au moins [0..255]) sont des types à vocation numérique.
La norme spécifie explicitement ces trois types, et permet d'implémenter char comme un signed ou unsigned char.

Pour des maths, il vaudrait mieux utiliser l'un des deux types explicites

[boboss123]

Pour des maths, il vaudrait mieux utiliser l'un des deux types explicites

Tout a fait d'accord (ou utiliser les types int8_t, ... car c'est plus explicites)

[kripteks]

Merci pour les réponses.
Même si je poste pas, je suis le sujet et fait mes recherches.

Sur mes recherches j'ai trouvé pas mal d'info.
L'arrière plan du C est pas mal compliqué ou plutôt peu connu/expliqué.

Voici un lien intéressent: http://ilay.org/yann/articles/mem/
Ça empire mes questionnements..

Par exemple, j'aimerais savoir: disons qu'on est en 64-bit, chaque adresse est composé de 8 octet ? si on utilise un int8_t, il reste 7 octet vide dans la même adresse ? si oui, ces 7 octets vide doivent rester vide ou d'autre int8-16-32 peuvent être inséré dedans ?

[Invité]

Attention, une adresse est différent de la zone qu'elle pointe.

Une adresse codé sur 32 ou 64bits peut très bien désigner un bout de zone mémoire qui lui ne fait qu'un octet (comme un char ou un int8_t par exemple).

La taille de l'adresse reste fixe, mais la taille zone mémoire qu'elle désigne, elle, peut varier.

[kripteks]

Bon, j'ai décidé de m'y mettre à l'assembleur, car c'est plus explicite pour apprendre ces détails, je ne penses pas les apprendre via C. Suite à cela je pourrais trouver logique/mieux comprendre le C.

[boboss123]

Bon, j'ai décidé de m'y mettre à l'assembleur, car c'est plus explicite pour apprendre ces détails, je ne penses pas les apprendre via C. Suite à cela je pourrais trouver logique/mieux comprendre le C.

Oui c'est toujours un plus de connaitre les bases de l'assembleur (pas besoin de devenir un expert). Le langage C étant un langage assez bas niveau, l'analogie entre le C et l'ASM est assez simple à comprendre.
=> avec les langage haut niveau qui sont de plus en plus utilisés, les programmeurs ont de moins en moins de connaissances sur le hardware et la gestion de la mémoire.

Les principales notions qu'il faut connaitre :
- La notion d'adressage et de bank mémoire. La notion de bus (hardware).
- La notion de registres.
- La notion d'instruction CPU (code machine).
- La notion de pile logicielle et hardware.
- Les interruptions.

J'ai pas mal appris en analysant des codes sources ASM générés à partir d'un code C (ex: comment faire une opération arithmétique, comment sont passés les arguments dans une fonction, ...).

[grim7reaper]

Ce qui est intéressant, c'est que c'est là quelque chose qui est propre à l'architecture cible et qu'à ma connaissance, bien que la norme évoque fréquemment les questions d'alignement, à aucun moment elle ne définit cela comme undefined behavour pour ce cas précis.

Si si, la norme le définit bien comme un undefined behavior, Cf. Annexe J2 :

Conversion between two pointer types produces a result that is incorrectly aligned (6.3.2.3)

Et la section 6.3.2.3, paragraphe 7 :

A pointer to an object or incomplete type may be converted to a pointer to a different object or incomplete type. If the resulting pointer is not correctly aligned for the pointed-to type, the behavior is undefined.