Déclaration en C

[Dlzlogic]

Bonjour,
Environnement Windows langage C de base.
Je trouve cette déclaration de fonction:
char *Unestring(unsigned long long value)

La répétition du type long, me parait bizarre, j'ai jamais vu ça.
Dans le source, le buffer est effectivement dimensionné à 64
La fonction serait une version superlong de IntToStr().
Par curiosité, j'ai été voir les appels, je n'ai vu que des unsigned long, c'est à dire des int sur 32 bits.
Peut-être est-ce pour tenir compte de OS à 64 bits ? Mais il semble me souvenir qu'il n'était prévu que pour W2000 et XP.

Merci d'avance.
-----

[invite1c6b0acc]

Bonjour,

Peut-être est-ce pour tenir compte de OS à 64 bits ?

Oui, c'est ça, mais ce n'est pas portable : pour gcc sous linux 64 bits (Ubuntu) les "long" font 64 bits, pour gcc sous Windows 7 les "long" font 32 bits et ce sont les "long long" qui font 64 bits. Et je parierais que d'autres compilateurs ont encore une autre définition.

Mais il semble me souvenir qu'il n'était prévu que pour W2000 et XP.

Non, c'est aussi vrai pour Windows 7.
C'est un peu le foutoir. Je ne sais pas ce que dit la norme ...
A+

[Jack]

D'après wikipedia, les long long ont ét ajoutés depuis C99

Pour le compilateur actuel de microsoft, la valeur est codée sur 64 bits

A+

[Dlzlogic]

Merci,
J'ai appris quelque-chose aujourd'hui.
Mais leur truc est pas clair de toute façon, un entier sur 64 bits n'aura pas besoin d'un buffer de 64 caractères pour faire une chaine.

[A voir en vidéo sur Futura]

[invite2d7144a7]

Bonjour,

Merci,
J'ai appris quelque-chose aujourd'hui.
Mais leur truc est pas clair de toute façon, un entier sur 64 bits n'aura pas besoin d'un buffer de 64 caractères pour faire une chaine.

Il n'est nulle part question "d'un buffer de 64 caractères".

Pour les types, il est très fortement conseillé d'utiliser les types définis dans stdint.h, qui ont des noms explicites (int32_t, uint64_t, ...), et sont garantis avoir la même taille d'un compilateur à l'autre, ce qui n'est pas le cas des types génériques (int, long int ...).

[Dlzlogic]

Bonjour,

Il n'est nulle part question "d'un buffer de 64 caractères".

Citation de ma question d'origine.

Dans le source, le buffer est effectivement dimensionné à 64

Pour les types, il est très fortement conseillé d'utiliser les types définis dans stdint.h, qui ont des noms explicites (int32_t, uint64_t, ...), et sont garantis avoir la même taille d'un compilateur à l'autre, ce qui n'est pas le cas des types génériques (int, long int ...).

Merci, je ferai passer le message à l'auteur de ce programme.

[Jack]

Il na faudrait pas réserver un emplacement supplémentaire pour le zéro terminal de la chaine?

PS : en y repensant, pourquoi un buffer de 64 finalement? C'a n'a pas grand chose à voir avec le nombre de bits de l'entier.

A+

[invite1c6b0acc]

Bonjour,

un entier sur 64 bits n'aura pas besoin d'un buffer de 64 caractères pour faire une chaine.

C'est clair : la valeur maxi (non signée) sur 64 bits est 2⁶⁴ soit à peu près 16*10¹⁸ soit 21 caractères en comptant le terminateur.
A+

[Dlzlogic]

@Jack
Si bien sûr, ce qui fait qu'il ne reste plus que 63 position disponibles.
J'aurais bien copié le code, mais il aurait fallu que je joigne tout le texte relatif à la licence, ça n'intéresse personne.
Donc, je résume le type unsigned long long peut donne en entier de 0 à 18446744073709551616, soit 20 caractères (sauf erreur). La fonction prévoit un buffer de 64 caractères. Compte tenu du 0 terminal, il y a 63 places disponibles.
Cependant, il y peut-être une petite astuce, le résultat est calé à droite avec une largeur fixe. Je pense que je trouverai la raison de cela plus tard. J'ai ouvert ce sujet seulement pour la répétition de "long", ce que je vois pour la première fois.

[Jack]

Si bien sûr, ce qui fait qu'il ne reste plus que 63 position disponibles.

Oui, oui, j'ai rectifié (un peu tard), mais il faut assumer ...

[invite2d7144a7]

Bonjour,

Citation de ma question d'origine

Ça m'avait échappé.
Il est possible que l'auteur utilise assez souvent cette taille de buffer, c'est assez fréquemment mon cas (mais avec 128).

Merci, je ferai passer le message à l'auteur de ce programme.

Ça te servira aussi.

Il faut se souvenir que C ne force pas la taille des types (à part char), et ne garantit que des tailles en fonction l'une de l'autre (enfin, petit bémol, int doit désormais faire 32 bits, mais ce n'est pas forcément le cas pour des compilateurs un peu vieux).

On doit avoir (taille de) char <= short <= int <= long int <= long long int.

Malgré le petit bémol cité plus haut, les valeurs relatives restent int <= long int <= long long int, et dépendent du compilateur (y compris de la version du compilateur pour un même éditeur).

Il est donc vraiment utile d'utiliser les types définis dans stdint.h.

C'est d'ailleurs également vrai pour les flottants, long double ne correspond pas à la même taille pour GCC que pour le compilateur de MS : pour MS, c'est la même chose que double, donc 8 octets, alors que pour GCC, ça fait 12 octets au lieu de 8 (sur ces 12 octets, seuls les 10 premiers sont effectivement utilisés, les 2 autres n'étant là que pour garantir un alignement sur une adresse multiple de 4 dans un tableau).