Dans l'article ,
Pascal Bourguignon écrit:Tout le monde est d'accord, ce serait mieux si c'était déclaré
unsigned int argc.
Non, je ne suis pas d'accord.Mais le mélange de types entier N-bit non signés et de types entier
N-bit signés en complément à deux est toujours problématique, car les
intervales ne sont pas imbriqués, mais ont une intersection bizarre.
Voilà, les types non signés posent des problèmes et sont sources de
bugs (une valeur négative se retrouve facilement convertie en valeur
positive). De plus, ils ne permettent pas un contrôle d'overflow via
des traps (cf option -ftrapv de gcc).
Déclarer un type non signé juste parce qu'une valeur négative n'a pas
de sens, c'est idiot.
En C, on le voit par les différent warnings qu'un compilateur donne,
et sur les erreurs invisible comises quand on mélange les deux.
Le compilateur ne donne pas toujours de warning. Le pire, c'est quand
ça marche en 32 bits, mais plus du tout en 64 bits, car les promotions
se font différemment (e.g. une promotion en un type signé devient une
promotion en un type non signé, d'où bug sur les valeurs négatives).
Dans l'article <87wsw3ihfr.fsf@informatimago.com>,
Pascal Bourguignon <pjb@informatimago.com> écrit:
Tout le monde est d'accord, ce serait mieux si c'était déclaré
unsigned int argc.
Non, je ne suis pas d'accord.
Mais le mélange de types entier N-bit non signés et de types entier
N-bit signés en complément à deux est toujours problématique, car les
intervales ne sont pas imbriqués, mais ont une intersection bizarre.
Voilà, les types non signés posent des problèmes et sont sources de
bugs (une valeur négative se retrouve facilement convertie en valeur
positive). De plus, ils ne permettent pas un contrôle d'overflow via
des traps (cf option -ftrapv de gcc).
Déclarer un type non signé juste parce qu'une valeur négative n'a pas
de sens, c'est idiot.
En C, on le voit par les différent warnings qu'un compilateur donne,
et sur les erreurs invisible comises quand on mélange les deux.
Le compilateur ne donne pas toujours de warning. Le pire, c'est quand
ça marche en 32 bits, mais plus du tout en 64 bits, car les promotions
se font différemment (e.g. une promotion en un type signé devient une
promotion en un type non signé, d'où bug sur les valeurs négatives).
Dans l'article ,
Pascal Bourguignon écrit:Tout le monde est d'accord, ce serait mieux si c'était déclaré
unsigned int argc.
Non, je ne suis pas d'accord.Mais le mélange de types entier N-bit non signés et de types entier
N-bit signés en complément à deux est toujours problématique, car les
intervales ne sont pas imbriqués, mais ont une intersection bizarre.
Voilà, les types non signés posent des problèmes et sont sources de
bugs (une valeur négative se retrouve facilement convertie en valeur
positive). De plus, ils ne permettent pas un contrôle d'overflow via
des traps (cf option -ftrapv de gcc).
Déclarer un type non signé juste parce qu'une valeur négative n'a pas
de sens, c'est idiot.
En C, on le voit par les différent warnings qu'un compilateur donne,
et sur les erreurs invisible comises quand on mélange les deux.
Le compilateur ne donne pas toujours de warning. Le pire, c'est quand
ça marche en 32 bits, mais plus du tout en 64 bits, car les promotions
se font différemment (e.g. une promotion en un type signé devient une
promotion en un type non signé, d'où bug sur les valeurs négatives).
Pascal Bourguignon écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Pascal Bourguignon <pjb@informatimago.com> écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Pascal Bourguignon écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Pascal Bourguignon écrivait :Erwan David writes:Pascal Bourguignon écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Il n'y a pas de type de taille fixe en C.
Si, en C99.Sauf à considérer char, mais sizeof(char)==1 n'est que tautologique,
il faut voir limit.h et CHAR_BIT.
et uint32_t ?
Pascal Bourguignon <pjb@informatimago.com> écrivait :
Erwan David <erwan@rail.eu.org> writes:
Pascal Bourguignon <pjb@informatimago.com> écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Il n'y a pas de type de taille fixe en C.
Si, en C99.
Sauf à considérer char, mais sizeof(char)==1 n'est que tautologique,
il faut voir limit.h et CHAR_BIT.
et uint32_t ?
Pascal Bourguignon écrivait :Erwan David writes:Pascal Bourguignon écrivait :
En C, oui. Mieux vaut mettre int partout, sauf dans le cas extrême
où on a besoin d'un bit de plus.
Mouais, moi je dis qu'il vaut mieux voire au cas par cas...
ET quand on peut utiliser les types de taille fixe plutôt que int qui
va poser des problèmes de portabilité (ah les joies du int 16 bits quand
on porte un programme 32 bits...)
Il n'y a pas de type de taille fixe en C.
Si, en C99.Sauf à considérer char, mais sizeof(char)==1 n'est que tautologique,
il faut voir limit.h et CHAR_BIT.
et uint32_t ?
Erwan David writes:
[...]
et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Erwan David <erwan@rail.eu.org> writes:
[...]
et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Erwan David writes:
[...]
et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Dans l'article ,
Pascal Bourguignon écrit:Erwan David writes:
[...]et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Existe-t-il des plateformes supportant C99 mais pas ces types?
Je suppose que leur absence risque de poser des problèmes de
portabilité, notamment pour les formats qui utilisent des mots
de 16 et 32 bits (le problème d'endianness est réglé par les
fonctions htonl, htons, ntohl et ntohs, que l'on peut facilement
réimplémenter sur les plateformes qui ne les ont pas). Bien sûr,
on peut se débrouiller avec des types uint_leastN_t et des
masques, mais ce genre de chose devrait être le travail du
compilateur, pas celui du programmeur.
Dans l'article <878x8hhbmi.fsf@informatimago.com>,
Pascal Bourguignon <pjb@informatimago.com> écrit:
Erwan David <erwan@rail.eu.org> writes:
[...]
et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Existe-t-il des plateformes supportant C99 mais pas ces types?
Je suppose que leur absence risque de poser des problèmes de
portabilité, notamment pour les formats qui utilisent des mots
de 16 et 32 bits (le problème d'endianness est réglé par les
fonctions htonl, htons, ntohl et ntohs, que l'on peut facilement
réimplémenter sur les plateformes qui ne les ont pas). Bien sûr,
on peut se débrouiller avec des types uint_leastN_t et des
masques, mais ce genre de chose devrait être le travail du
compilateur, pas celui du programmeur.
Dans l'article ,
Pascal Bourguignon écrit:Erwan David writes:
[...]et uint32_t ?
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
Existe-t-il des plateformes supportant C99 mais pas ces types?
Je suppose que leur absence risque de poser des problèmes de
portabilité, notamment pour les formats qui utilisent des mots
de 16 et 32 bits (le problème d'endianness est réglé par les
fonctions htonl, htons, ntohl et ntohs, que l'on peut facilement
réimplémenter sur les plateformes qui ne les ont pas). Bien sûr,
on peut se débrouiller avec des types uint_leastN_t et des
masques, mais ce genre de chose devrait être le travail du
compilateur, pas celui du programmeur.
Il n'y a pas de type de taille fixe en C.
Si, en C99.
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.ps.gz
section 7.18.1.1
Il n'y a pas de type de taille fixe en C.
Si, en C99.
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.ps.gz
section 7.18.1.1
Il n'y a pas de type de taille fixe en C.
Si, en C99.
Je n'ai pas le C99 lui-même, mais le final draft indique que ces types
de largeur exacte ne sont pas forcément présent (ce qui s'explique,
par exemple sur un processeur 36-bit).
http://wwwold.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.ps.gz
section 7.18.1.1
L'alinéa 3, qui n'était pas présent dans le FDIS, est intéressant
dans ce contexte (historiquement, cet alinéa a été rajouté par des
pinailleurs, pour éviter les argucies d'autres pinailleurs comme
quoi une implémentation pouvait se permettre de ne pas définir ces
types, alors même qu'il est évident qu'une telle implémentation
n'aurait aucun succès commercial, donc ne représenterait aucun
intérêt réel en dehors des pinaillages.)
Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Autrement dit, si tu utilises int32_t, ton programme va planter à la
compilation sur un symbole non défini.
Cela tombe bien, sur une machine 36 bits il n'y a pas de bonne manière de
manipuler une quantité sur 16 ou 32 bits (surtout non signée.) Le programme,
si les types sont utilisés à bon escient, est donc maximalement portable !
L'alinéa 3, qui n'était pas présent dans le FDIS, est intéressant
dans ce contexte (historiquement, cet alinéa a été rajouté par des
pinailleurs, pour éviter les argucies d'autres pinailleurs comme
quoi une implémentation pouvait se permettre de ne pas définir ces
types, alors même qu'il est évident qu'une telle implémentation
n'aurait aucun succès commercial, donc ne représenterait aucun
intérêt réel en dehors des pinaillages.)
Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Autrement dit, si tu utilises int32_t, ton programme va planter à la
compilation sur un symbole non défini.
Cela tombe bien, sur une machine 36 bits il n'y a pas de bonne manière de
manipuler une quantité sur 16 ou 32 bits (surtout non signée.) Le programme,
si les types sont utilisés à bon escient, est donc maximalement portable !
L'alinéa 3, qui n'était pas présent dans le FDIS, est intéressant
dans ce contexte (historiquement, cet alinéa a été rajouté par des
pinailleurs, pour éviter les argucies d'autres pinailleurs comme
quoi une implémentation pouvait se permettre de ne pas définir ces
types, alors même qu'il est évident qu'une telle implémentation
n'aurait aucun succès commercial, donc ne représenterait aucun
intérêt réel en dehors des pinaillages.)
Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Autrement dit, si tu utilises int32_t, ton programme va planter à la
compilation sur un symbole non défini.
Cela tombe bien, sur une machine 36 bits il n'y a pas de bonne manière de
manipuler une quantité sur 16 ou 32 bits (surtout non signée.) Le programme,
si les types sont utilisés à bon escient, est donc maximalement portable !
Dans l'article <fae21c$689$,
Antoine Leca écrit:Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
Dans l'article <fae21c$689$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
Dans l'article <fae21c$689$,
Antoine Leca écrit:Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
En news:20070821075409$, Vincent Lefevre va
escriure:Dans l'article <fae21c$689$,
Antoine Leca écrit:Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Pas d'accord. Sur une machine 36 bits, un tel type sera inefficace
(masquage etc.),
donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
Je n'ai pas la réponse définitive, mais je me demande dans quelle
mesure les dites implémentations ont fait cela « parce que c'était
utile dans la pratique », ou bien si c'était sous la pression des
utilisateurs [payants ou internes] qui n'arrivaient pas à recompiler
leurs programmes qui assumaient de manière aveugle que
short===int16_t (alias la dictature du Vax).
La même logique a servie récemment à Microsoft pour décider que
DWORD===long===int32_t, y compris avec Win64, ce qui laisse la plateforme
supposément phare sans un vrai type entier de la largeur naturelle de la
plateforme... (ou comment couler le langage C sur la dite plateforme ?)
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short en
vue...
En news:20070821075409$73fc@prunille.vinc17.org, Vincent Lefevre va
escriure:
Dans l'article <fae21c$689$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Pas d'accord. Sur une machine 36 bits, un tel type sera inefficace
(masquage etc.),
donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
Je n'ai pas la réponse définitive, mais je me demande dans quelle
mesure les dites implémentations ont fait cela « parce que c'était
utile dans la pratique », ou bien si c'était sous la pression des
utilisateurs [payants ou internes] qui n'arrivaient pas à recompiler
leurs programmes qui assumaient de manière aveugle que
short===int16_t (alias la dictature du Vax).
La même logique a servie récemment à Microsoft pour décider que
DWORD===long===int32_t, y compris avec Win64, ce qui laisse la plateforme
supposément phare sans un vrai type entier de la largeur naturelle de la
plateforme... (ou comment couler le langage C sur la dite plateforme ?)
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short en
vue...
En news:20070821075409$, Vincent Lefevre va
escriure:Dans l'article <fae21c$689$,
Antoine Leca écrit:Il reste qu'une implémentation sur 36 bits ne définira pas ces types.
Elle pourrait les définir.
Pas d'accord. Sur une machine 36 bits, un tel type sera inefficace
(masquage etc.),
donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Certains processeurs ne sont
pas capables de manipuler des mots sur 16 bits, et pourtant les
implémentations fournissent bien un short sur 16 bits parce que
c'est utile dans la pratique.
Je n'ai pas la réponse définitive, mais je me demande dans quelle
mesure les dites implémentations ont fait cela « parce que c'était
utile dans la pratique », ou bien si c'était sous la pression des
utilisateurs [payants ou internes] qui n'arrivaient pas à recompiler
leurs programmes qui assumaient de manière aveugle que
short===int16_t (alias la dictature du Vax).
La même logique a servie récemment à Microsoft pour décider que
DWORD===long===int32_t, y compris avec Win64, ce qui laisse la plateforme
supposément phare sans un vrai type entier de la largeur naturelle de la
plateforme... (ou comment couler le langage C sur la dite plateforme ?)
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short en
vue...
Dans l'article <fae96t$vv8$,
Antoine Leca écrit:donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Non, ce sont les (u)int_fastN_t qui ont été ajoutés pour la
performance.
Un des problèmes est que
certaines structures liées au système ont des données sur 16 bits,
et avant C99, short était plus ou moins de seul moyen pour cela.
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short
en vue...
Oui, mais ce n'est pas très pratique et probablement inefficace.
Et peu de programmeurs font cela, d'où problème si tu veux porter
des logiciels.
Dans l'article <fae96t$vv8$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Non, ce sont les (u)int_fastN_t qui ont été ajoutés pour la
performance.
Un des problèmes est que
certaines structures liées au système ont des données sur 16 bits,
et avant C99, short était plus ou moins de seul moyen pour cela.
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short
en vue...
Oui, mais ce n'est pas très pratique et probablement inefficace.
Et peu de programmeurs font cela, d'où problème si tu veux porter
des logiciels.
Dans l'article <fae96t$vv8$,
Antoine Leca écrit:donc il me paraît plus utile de ne PAS définir ces types, justement
pour éviter qu'un programme qui cherche à utiliser une
fonctionnalité supposément à des fins de performances (c'est ce
pourquoi ces types ont été ajoutés) ne se fourvoit.
Non, ce sont les (u)int_fastN_t qui ont été ajoutés pour la
performance.
Un des problèmes est que
certaines structures liées au système ont des données sur 16 bits,
et avant C99, short était plus ou moins de seul moyen pour cela.
Dans les cas un poil moins spécifiques, je me retrouve à utiliser des
unsigned char et à dépouiller à la main les structures, pas de short
en vue...
Oui, mais ce n'est pas très pratique et probablement inefficace.
Et peu de programmeurs font cela, d'où problème si tu veux porter
des logiciels.