Discussion :

[Médinoc]

Faire un test n'est quand même pas si terrible que ça, et de plus permet d'afficher un message que ça s'est mal passé quelque part..

Tu parles du snprintf() là? Dans ce cas, tu n'as absolument pas compris l'intérêt, qui est de savoir combien allouer.

[Melem]

Les modifs du compilo C99 m'importent peu, mais c'est la bibliothèque standard que je trouve plus importante:

Moi par contre j'aime plus les rectifications de la syntaxe que les nouveautés de la bibliothèque standard, mais c'est vrai qu'on a toujours pu s'en passer et je considère également <stdint.h> et snprintf comme les nouveautés les plus importantes de la bibliothèque standard. <stdbool.h> ne m'est pas aussi important. D'autre part, bien que snprintf permet de se simplifier énormément la vie par rapport à sprintf, sprintf n'est cependant pas un danger absolu (comme fgets), parce qu'elle offre quand même des moyens de contrôler la longueur max de la chaîne formatée grâce aux champs "précision" dans les spécifications de format ...

Par contre, cela ne me dérange pas que MS ne supporte que tres partiellement le C99 (notons tout de même le long long et wchar_t) car (...) La plupart des modifs du C99 sont plus la pour gommer les différences syntaxique entre C et C++ qu'autre chose

+1. Sauf que les wchar_t sont bel et bien ISO C90 (Amendment 1) . Et il y a quand même aussi d'autres trucs intéressants comme :

Code :

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

1
2
3
4
5
6
fonc_qui_prend_tab_en_param(..., {1, 2, 3, ...}, ...);
fonc(int n, int m)
{
    int tab[n][m];
    ...
}

Non ?

stdint, je nen vois strictement aucun intérêt

Il y a pas mal de gens, y compris moi, qui ont besoin d'utiliser des entiers de taille connue à l'avance dans certains programmes (notamment mathématiques/cryptographie). Faire des #if pour les milliers de plateformes existantes, ça ne me convainc pas beaucoup ...

[Vincent Rogier]

+1. Sauf que les wchar_t sont bel et bien ISO C90 (Amendment 1) ...

Bon, comme certains sont tatillons, le type de donnée wchar_t a été introduit dans l'amendement I de l'ISO C90 en Septembre 1994, soit quasi 5 ans apres la sortie du C90.

Pour ma part, je ne considère pas vraiment le support officiel et complet de wchar_t acquis dans cet amendement.
D'une part parce que certains fonctions sur les caractères larges y manquent et d'autre part, l'amendement de 95 étant tout de même largement postérieur la version initiale du C90.
D'autre part, parce que les diférents compilateur ayant déja implémentés progressivement les caractères larges et les fonctions qui vont avec avant/pendant/apres cet amendement, seules les versions des compilos C datant de la fin des années 90 et début 2000 sont vraiment conformes à l'amendement de 95 en termes de spécifications

C'est pourquoi, je fais souvent le raccourci support caractères larges = C99

[edit : De plus __STDC_ISO_10646__ n'a été proposé que par le C99]

[Médinoc]

De toute façon, dans aucun des deux le standard ne spécifie la prise en charge des caractères larges par les fichiers texte (enfin, ça "passe" peut-être sous un Linux réglé en UTF-8. Mais toujours pas sous MinGW, et Visual utilise sa propre extension).

[Melem]

C'est pourquoi, je fais souvent le raccourci support caractères larges = C99

Ouais, je crois que t'as raison.

De plus __STDC_ISO_10646__ n'a été proposé que par le C99

Mais ça se trouve en annexe si je me rappelle bien. Normal, ça n'a aucune chance de se voir imposé partout.

[souviron34]

Tu parles du snprintf() là? Dans ce cas, tu n'as absolument pas compris l'intérêt, qui est de savoir combien allouer.

Bof..


Je ne dois vraiment pas avoir compris l'intérêt...

Il y a pas mal de gens, y compris moi, qui ont besoin d'utiliser des entiers de taille connue à l'avance dans certains programmes (notamment mathématiques/cryptographie). Faire des #if pour les milliers de plateformes existantes, ça ne me convainc pas beaucoup ...

Euh, rappelle-moi , on parle bien de 8, 16, 32, 64 et 128 ??

Soit 5 define et une seule fonction de test en tout et pour tout, non ??

[Melem]

Bof..

Je ne dois vraiment pas avoir compris l'intérêt...

On dit souvent que sprintf est une fonction dangereuse parce qu'elle ne possède pas d'argument pour préciser la taille du buffer (d'où risque de débordement de tampon, un peu le même problème que gets) mais en fait je pense que ça ne tient pas trop puisque cette taille elle peut se préciser, certes de manière pas très explicite, dans la chaîne de formatage.

Euh, rappelle-moi , on parle bien de 8, 16, 32, 64 et 128 ??

Soit 5 define et une seule fonction de test en tout et pour tout, non ??

Alors définis-nous un peu juste un type entier de taille exactement égale 16 bits en C90.

[Pouet_forever]

C'est chiant de faire ça t'es obligé de taper tous les if, elif :o

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
#include <limits.h>
 
#if UCHAR_MAX == 0xFFFF
typedef char int16_bits;
typedef unsigned char uint16_bits;
#elif USHRT_MAX == 0xFFFF
typedef short int16_bits;
typedef unsigned short uint16_bits;
#elif UINT_MAX == 0xFFFF
typedef int int16_bits;
typedef unsigned int uint16_bits;
#endif

[Melem]

Et si UCHAR_MAX != 0xFFFF et USHRT_MAX != 0xFFFF et UINT_MAX != 0xFFFF ?

[Pouet_forever]

Code :

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

#error Impossible d'avoir un nombre de 16 bits

:p
D'après la norme ULONG_MAX ne peut être inférieur à 4294967295 donc 32 bits. Donc si toutes mes conditions sont fausses bah tu ne peux rien faire ^^

[souviron34]

Alors définis-nous un peu juste un type entier de taille exactement égale 16 bits en C90.

ne confondrais-tu pas "écrire un nobre entier sur 16 bits" et "utiliser un nobre entier sur 16 bits" ??

Pour l'utiliser, tu passes sur une machine 16, ou tu connais ta machine et tu utilises des shorts. Et tu n'as que 3 tests à faire..

Pour l'écrire , tu fais des shifts dans des bytes contigus..

[Melem]

D'après la norme ULONG_MAX ne peut être inférieur à 4294967295 donc 32 bits

Mais je veux un type qui fait exactement 16 bits, pas au moins 16 bits. Et je suis encore gentil parce que j'ai choisi 16 au lieu de 64 par exemple.

Donc si toutes mes conditions sont fausses bah tu ne peux rien faire ^^

CQFD .

ne confondrais-tu pas "écrire un nobre entier sur 16 bits" et "utiliser un nobre entier sur 16 bits" ??

Je veux juste définir un type entier de taille exactement égale à 16 bits. La question n'est quand même pas compliquée !

Pour l'utiliser, tu passes sur une machine 16, ou tu connais ta machine et tu utilises des shorts.

Là tu dépends d'un type particulier de machine, ce n'est pas portable.

[souviron34]

Là tu dépends d'un type particulier de machine, ce n'est pas portable.

peux-tu me dire qu'est-ce qui ne va pas avec :

type short

SHRT_MIN Minimum value for a short int –32,768 ≤–32,767
SHRT_MAX Maximum value for a short int +32,767 ≥+32,767

dans limits.h (C90)

par rapport à :

int16_t short Signed 16 2 −32,768 32,767

dans stdint.h (C99) ???

[gl]

Donc si toutes mes conditions sont fausses bah tu ne peux rien faire ^^

CQFD .

Soit dit au passage, C99 ne résous ce problème puisque le support des types intX_t est optionnel et qu'un environnement peut donc être conforme C99 sans les proposer.

Pour l'utiliser, tu passes sur une machine 16, ou tu connais ta machine et tu utilises des shorts.

Là tu dépends d'un type particulier de machine, ce n'est pas portable.

Il n'est pas portable de supposer qu'un short ait exactement 16 bits. Par contre il est tout à fait portable de supposer qu'un short puisse contenir tout nombre compris entre -32767 et 32767.

[Melem]

souviron34, je ne t'apprends rien en disant ceci mais je veux juste éclaircir les choses :

C90 :
Le type short a une taille au moins égale à 16 bits. Au moins égale à 16 bits signifie que ça peut être 16 bits, 17 bits, 18 bits, 32 bits, 128 bits, 130 bits, etc. Ce n'est pas ce que je veux. Ce que je veux, c'est un entier de taille exactement égale à 16 bits. Je ne sais plus combien de fois j'ai répété cela. Comment déclares-tu un tel type en C90 ? Je ne te demande pas de réellement trouver une solution, simplement parce qu'il n'y en a pas, c'est juste une question pour faire penser.

C99 :
int16_t n'est pas un typedef de short. C'est un type entier de taille exactement égale à 16 bits qui est un typedef d'un type défini par l'implémentation. Maintenant, il est possible que dans ton implémentation, on ait typedef short int16_t (ce qui signifie que la taille d'un short, dans cette implémentation, est d'exactement 16 bits).

Soit dit au passage, C99 ne résous ce problème puisque le support des types intX_t est optionnel et qu'un environnement peut donc être conforme C99 sans les proposer.

Evidemment, parce qu'il n'est pas garanti que l'unité d'allocation sur toutes les machines soit un sous-multiple de X. Mais ça peut résoudre quelque chose :

Du moment que tu développes un programme qui ait besoin d'un entier de taille exactement égale à X bits, cela signifie que tu cibles tout au plus une famille d'architectures bien déterminées et que ton programme ne doit fonctionner que SI ce type existe. La norme C99 dit justement que si un tel type existe sur la cible, qu'il soit défini sinon, qu'il ne soit pas défini. Si ton programme utilisant intX_t ne compile pas, c'est qu'il n'a aucune chance de fonctionner correctement sur la plateforme cible (et dans ce cas, on admettra qu'une erreur à la compilation est de loin meilleur qu'une erreur à l'exécution ...). Si tu veux quand même qu'il fonctionne, alors c'est le choix de int16_t même qui était une erreur (aurais-tu du utiliser short par exemple ...).

Il n'est pas portable de supposer qu'un short ait exactement 16 bits. Par contre il est tout à fait portable de supposer qu'un short puisse contenir tout nombre compris entre -32767 et 32767.

Sauf comme je viens de le répéter, que ce n'est pas ce que je cherche.

[gl]

C99 :
int16_t n'est pas un typedef de short. C'est un type entier de taille exactement égale à 16 bits qui est un typedef d'un type défini par l'implémentation. Maintenant, il est possible que dans ton implémentation, on ait typedef short int16_t (ce qui signifie que la taille d'un short, dans cette implémentation, est d'exactement 16 bits).

Juste une petite précision complémentaire : les types intX_t garantissent une taille exacte mais également l'absence de bits de padding et, pour les types signés, une représentation en complément à 2.

Soit dit au passage, C99 ne résous ce problème puisque le support des types intX_t est optionnel et qu'un environnement peut donc être conforme C99 sans les proposer.

Evidemment, parce qu'il n'est pas garanti que l'unité d'allocation sur toutes les machines soit un sous-multiple de X. Mais ça peut résoudre quelque chose :

Du moment que tu développes un programme qui ait besoin d'un entier de taille exactement égale à X bits, cela signifie que tu cibles tout au plus une famille d'architectures bien déterminées et que ton programme ne doit fonctionner que SI ce type existe. La norme C99 dit justement que si un tel type existe sur la cible, qu'il soit défini sinon, qu'il ne soit pas défini. Si ton programme utilisant intX_t ne compile pas, c'est qu'il n'a aucune chance de fonctionner correctement sur la plateforme cible (et dans ce cas, on admettra qu'une erreur à la compilation est de loin meilleur qu'une erreur à l'exécution ...). Si tu veux quand même qu'il fonctionne, alors c'est le choix de int16_t même qui était une erreur (aurais-tu du utiliser short par exemple ...).

Il n'est pas portable de supposer qu'un short ait exactement 16 bits. Par contre il est tout à fait portable de supposer qu'un short puisse contenir tout nombre compris entre -32767 et 32767.

Sauf comme je viens de le répéter, que ce n'est pas ce que je cherche.

Tout a fait d'accord.

Mon but n'était pas de nier l'intérêt de ces types [1] (ni de prétendre connaître mieux ton besoin que toi) mais seulement de préciser ces deux petits points qui, même si je ne doute pas que tu les connaissent, n'étaient pas explicite dans le message.

Ceci étant, concernant la disponibilité de ces types, c'est un tout petit peu plus compliqué que ça. Il est possible d'avoir une implémentation conforme qui dispose d'un type entier signé de 16 bits mais pas de int16_t si cette implémentation n'utilise pas le complément à 2.
Même s'il faut l'avouer ça ne doit pas être fréquent.



[1] D'autant moi que j'ai déjà eu besoin de tels types de taille précise, même si au final, pour différentes rasions, on est parti sur la définition de nos propres types "taille fixe".

[souviron34]

@Melem:

"fin bref, c'est bizarre, mais comment ont fait les auteurs de X, de HTML, de Mosaic, de Netscape, de Gnome, de KDE, de MacOS, et tout un tas d'autres qui ont fait du traitement d'images et de l'affichage d'image et/ou de portions d'écrans en 2, 4, 8, 12, 16, 24, 32 bits avant l'apparition de ces types ?????



Je peux te sortir les codes de xv, de Mosaic, il n'ya pas 36000 lignes.. Juste un test : if 16 alors short if 32 alors int....

M'enfin je dis n'importe quoi, hein...