Dans le cas du sizeof((signed|unsigned) char), c'est tellement rare que dans la pratique les quelques cas spécifiques (à la DSP, par exemple) seront de toute manière tellement bien cadrés que cela ne posera pa de problèmes.
Qu'est-ce qui est tellement rare?
Je me demande dans quelle mesure Xavier ne s'imagine pas qu'il soit possible que sizeof(char) soit different de 1. C'est qui est faux. Si c'est bien le cas, il confond vraissemblablement avec le fait que CHAR_BIT peut etre different de 8.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <ephmnq$o00$1@news.httrack.net>,
Xavier Roche <xroche@free.fr.nospam.invalid> écrit:
Dans le cas du sizeof((signed|unsigned) char), c'est tellement rare que
dans la pratique les quelques cas spécifiques (à la DSP, par exemple)
seront de toute manière tellement bien cadrés que cela ne posera pa de
problèmes.
Qu'est-ce qui est tellement rare?
Je me demande dans quelle mesure Xavier ne s'imagine pas qu'il soit
possible que sizeof(char) soit different de 1. C'est qui est faux. Si
c'est bien le cas, il confond vraissemblablement avec le fait que CHAR_BIT
peut etre different de 8.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Dans le cas du sizeof((signed|unsigned) char), c'est tellement rare que dans la pratique les quelques cas spécifiques (à la DSP, par exemple) seront de toute manière tellement bien cadrés que cela ne posera pa de problèmes.
Qu'est-ce qui est tellement rare?
Je me demande dans quelle mesure Xavier ne s'imagine pas qu'il soit possible que sizeof(char) soit different de 1. C'est qui est faux. Si c'est bien le cas, il confond vraissemblablement avec le fait que CHAR_BIT peut etre different de 8.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Antoine Leca
Xavier Roche écrivit dans news:epghne$uri$:
Moi, je défini mon buffer ainsi : uint8_t buf[1024];
Moi j'aurais mis unsigned char buf[1024];
C'est le plus portable, le plus universel.
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où cela compile, avec un compilo "ANSI") que cela sera promu en int (signé); avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même s'il sera plus «universel»).
Parce que bon, les architectures où sizeof(char) != 1, on doit en voir une fois dans sa vie, quand on a atteint l'âge de la retraite.
En tous cas, ce n'est pas du C, donc ce n'est pas l'objet ici.
Antoine
Xavier Roche écrivit dans news:epghne$uri$4@news.httrack.net:
Moi, je défini mon buffer ainsi :
uint8_t buf[1024];
Moi j'aurais mis
unsigned char buf[1024];
C'est le plus portable, le plus universel.
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où
cela compile, avec un compilo "ANSI") que cela sera promu en int (signé);
avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une
gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même
s'il sera plus «universel»).
Parce que bon, les architectures où sizeof(char) != 1, on doit en voir
une fois dans sa vie, quand on a atteint l'âge de la retraite.
En tous cas, ce n'est pas du C, donc ce n'est pas l'objet ici.
Moi, je défini mon buffer ainsi : uint8_t buf[1024];
Moi j'aurais mis unsigned char buf[1024];
C'est le plus portable, le plus universel.
Le gros intérêt de uint8_t[], c'est que tu est sûr (à partir du moment où cela compile, avec un compilo "ANSI") que cela sera promu en int (signé); avec ton unsigned char, tu n'as plus cette garantie ; et ce peut être une gêne pour ton algorithme, qui va devenir plus complexe, moins clair (même s'il sera plus «universel»).
Parce que bon, les architectures où sizeof(char) != 1, on doit en voir une fois dans sa vie, quand on a atteint l'âge de la retraite.
En tous cas, ce n'est pas du C, donc ce n'est pas l'objet ici.
Antoine
Antoine Leca
Marc Espie écrivit dans news:epi1g5$2h8m$:
Bof... je te rappelle que toutes les merdouilles de int != void* qu'on voit aujourd'hui correspondent directement a du code ecrit il y a 5 a 10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui pensaient qu'il « n'y avait au monde que des Vaxen. »
Antoine
Marc Espie écrivit dans news:epi1g5$2h8m$1@biggoron.nerim.net:
Bof... je te rappelle que toutes les merdouilles de int != void* qu'on
voit aujourd'hui correspondent directement a du code ecrit il y a 5 a
10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on
avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui
pensaient qu'il « n'y avait au monde que des Vaxen. »
Bof... je te rappelle que toutes les merdouilles de int != void* qu'on voit aujourd'hui correspondent directement a du code ecrit il y a 5 a 10 ans,
Euh... Au beau milieu des années 80 (cela fait plus de 20 ans, donc), on avait déjà des critiques à l'encontre des ces @&*! de programmeurs qui pensaient qu'il « n'y avait au monde que des Vaxen. »
Antoine
Antoine Leca
Pierre Maurette écrivit dans news::
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent : - soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser des problèmes sur les machines où l'espace d'adressage réel atteint les limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits, pour supporter les pointeurs lointains. Ou 64 bits sur les machines actuelles.
Antoine
Pierre Maurette écrivit dans news:mn.e32a7d71ef6e04a3.31483@laposte.net:
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent :
- soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser
des problèmes sur les machines où l'espace d'adressage réel atteint les
limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de
fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits,
pour supporter les pointeurs lointains. Ou 64 bits sur les machines
actuelles.
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent : - soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser des problèmes sur les machines où l'espace d'adressage réel atteint les limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits, pour supporter les pointeurs lointains. Ou 64 bits sur les machines actuelles.
Antoine
Jean Pierre Daviau
J'ai trouver sous java que pour transformer un byte en entier on utilise : (buffer[0] & 0xff) | ((buffer[1] & 0xff) << 8) | ((buffer[2] & 0xff) << 16) | (buffer[3] << 24)
Estg-ce la même chose en C? Qu'est-ce que tu ne comprends pas ?
couleur en nombre 32 bits 8 Rouge, plus 8 bleu plus 8 vert 8 transparence (alpha channel) 1000000 00000000 00000000 00000000
rouge nombre 8 bits (de 0 à 255 d'intensité) donc un octet non signé 10000000
si tu veux placer un rouge pur en 32 bits dans la case des rouges et être certain qu'il n'est pas signé (autrement il vaudra 0) 10000000 &0xff << 32
Il y a un modèle pour les gifs, tga, rgb, cmyk, etc.
Tu peux passer une vie là-dessus.
M'enfin... je suis peut-être dans le champ
Antoine Leca
Marc Espie écrivit dans news:epi71p$2jab$:
On peut se demander a quoi sert INT8_MAX, puisque c'est de toutes facons 127...
Je suis sûr qu'en fouillant on peut trouver des implémentation où cela va être (int8_t)127. Ce qui n'est pas exactement pareil (par exemple, si tu fais sizeof dessus).
Ok, je chipote.
Mais c'est une facon de verifier que le type int8_t existe, et d'ecrire le code conditionnel qui va avec.
Mmmm. Pas sûr que ce soit garanti ; c'est-à-dire, je ne suis pas sûr que l'on puisse écrire tranquillement #ifdef INT8_MIN // on est sûr que int8_t est défini #else /* on est sûr que int8_t n'est pas défini */ #endif
Le deuxième « sûr » est évidemment faux (<intypes.h> définit int8_t depuis des années sur *nix, sans définir INT8_MIN); mais même le premier ne me paraît pas absolument garanti par la rédaction de 7.18.2, même si les paris sont plutôt bons à prendre (comparer 7.18.2 avec 7.18.3p2, version TC2/N1124; sans compter ceux qui ne respectent pas la norme...)
In article , Pierre Maurette wrote:
Par exemple typedef unsigned char octet_t; typedef unsigned char uByte_t; typedef unsigned char sByte_t;
Mmm. J'eus bien vu typedef signed char sByte_t;
Mais c'est un avis personnel. :-)
Antoine
Marc Espie écrivit dans news:epi71p$2jab$1@biggoron.nerim.net:
On peut se demander a quoi sert INT8_MAX, puisque c'est de
toutes facons 127...
Je suis sûr qu'en fouillant on peut trouver des implémentation où cela va
être (int8_t)127. Ce qui n'est pas exactement pareil (par exemple, si tu
fais sizeof dessus).
Ok, je chipote.
Mais c'est une facon de verifier que le type int8_t existe, et
d'ecrire le code conditionnel qui va avec.
Mmmm. Pas sûr que ce soit garanti ; c'est-à-dire, je ne suis pas sûr que
l'on puisse écrire tranquillement
#ifdef INT8_MIN
// on est sûr que int8_t est défini
#else
/* on est sûr que int8_t n'est pas défini */
#endif
Le deuxième « sûr » est évidemment faux (<intypes.h> définit int8_t depuis
des années sur *nix, sans définir INT8_MIN); mais même le premier ne me
paraît pas absolument garanti par la rédaction de 7.18.2, même si les paris
sont plutôt bons à prendre (comparer 7.18.2 avec 7.18.3p2, version
TC2/N1124; sans compter ceux qui ne respectent pas la norme...)
In article <mn.e2fd7d7101ddd755.31483@laposte.net>, Pierre Maurette wrote:
Par exemple
typedef unsigned char octet_t;
typedef unsigned char uByte_t;
typedef unsigned char sByte_t;
On peut se demander a quoi sert INT8_MAX, puisque c'est de toutes facons 127...
Je suis sûr qu'en fouillant on peut trouver des implémentation où cela va être (int8_t)127. Ce qui n'est pas exactement pareil (par exemple, si tu fais sizeof dessus).
Ok, je chipote.
Mais c'est une facon de verifier que le type int8_t existe, et d'ecrire le code conditionnel qui va avec.
Mmmm. Pas sûr que ce soit garanti ; c'est-à-dire, je ne suis pas sûr que l'on puisse écrire tranquillement #ifdef INT8_MIN // on est sûr que int8_t est défini #else /* on est sûr que int8_t n'est pas défini */ #endif
Le deuxième « sûr » est évidemment faux (<intypes.h> définit int8_t depuis des années sur *nix, sans définir INT8_MIN); mais même le premier ne me paraît pas absolument garanti par la rédaction de 7.18.2, même si les paris sont plutôt bons à prendre (comparer 7.18.2 avec 7.18.3p2, version TC2/N1124; sans compter ceux qui ne respectent pas la norme...)
In article , Pierre Maurette wrote:
Par exemple typedef unsigned char octet_t; typedef unsigned char uByte_t; typedef unsigned char sByte_t;
Mmm. J'eus bien vu typedef signed char sByte_t;
Mais c'est un avis personnel. :-)
Antoine
Antoine Leca
Radamanthe écrivit dans news:45bccf2b$0$30521$:
Dans le contexte de ton exemple :
J'ai trouver sous java que pour transformer un byte en entier on utilise : (buffer[0] & 0xff) | ((buffer[1] & 0xff) << 8) | ((buffer[2] & 0xff) > << 16) | (buffer[3] << 24)
Si buffer est un byte[], l'expression buffer[x] est convertie en int (de la conversion du byte lu dans l'intervalle [-128,127]). Si le tableau contient en réalité des valeurs non-signées (intervalle [0,255]), faire "& 0xff" assure que le signe de l'entier est supprimé.
<PINAILLAGE> Avec Java (qui garanti l'arithmétique en complément à deux), oui. En C, ce peut être parfois faux. </PINAILLAGE> Dans la pratique, ce n'est pas un problème, une machine qui n'est pas en complément à deux va présenter d'autres aspects « intéressants » (à commencer par l'ordre des octets); et de toutes manières on aura depuis longtemps forcer buffer à être d'un type non signé pour réduire les problèmes.
Pour moi, un byte, c'est 8 bits, donc un entier entre 0 et 255.
Non. Attention à la terminologie différente d'un langage à l'autre !
Un "byte" est un terme anglais qui se traduit en français par "multiplet" et signifie "plus petit élément adressable".
En C. En Java, c'est un octet (signé), et aussi le "plus petit élément adressable".
Antoine
Radamanthe écrivit dans news:45bccf2b$0$30521$426a74cc@news.free.fr:
Dans le contexte de ton exemple :
J'ai trouver sous java que pour transformer un byte en entier on
utilise :
(buffer[0] & 0xff) | ((buffer[1] & 0xff) << 8) | ((buffer[2] &
0xff) > << 16) | (buffer[3] << 24)
Si buffer est un byte[], l'expression buffer[x] est convertie en int
(de la conversion du byte lu dans l'intervalle [-128,127]). Si le
tableau contient en réalité des valeurs non-signées (intervalle
[0,255]), faire "& 0xff" assure que le signe de l'entier est supprimé.
<PINAILLAGE>
Avec Java (qui garanti l'arithmétique en complément à deux), oui.
En C, ce peut être parfois faux.
</PINAILLAGE>
Dans la pratique, ce n'est pas un problème, une machine qui n'est pas en
complément à deux va présenter d'autres aspects « intéressants » (à
commencer par l'ordre des octets); et de toutes manières on aura depuis
longtemps forcer buffer à être d'un type non signé pour réduire les
problèmes.
Pour moi, un byte, c'est 8 bits, donc un entier entre 0 et 255.
Non. Attention à la terminologie différente d'un langage à l'autre !
Un "byte" est un terme anglais qui se traduit en français par
"multiplet" et signifie "plus petit élément adressable".
En C.
En Java, c'est un octet (signé), et aussi le "plus petit élément
adressable".
J'ai trouver sous java que pour transformer un byte en entier on utilise : (buffer[0] & 0xff) | ((buffer[1] & 0xff) << 8) | ((buffer[2] & 0xff) > << 16) | (buffer[3] << 24)
Si buffer est un byte[], l'expression buffer[x] est convertie en int (de la conversion du byte lu dans l'intervalle [-128,127]). Si le tableau contient en réalité des valeurs non-signées (intervalle [0,255]), faire "& 0xff" assure que le signe de l'entier est supprimé.
<PINAILLAGE> Avec Java (qui garanti l'arithmétique en complément à deux), oui. En C, ce peut être parfois faux. </PINAILLAGE> Dans la pratique, ce n'est pas un problème, une machine qui n'est pas en complément à deux va présenter d'autres aspects « intéressants » (à commencer par l'ordre des octets); et de toutes manières on aura depuis longtemps forcer buffer à être d'un type non signé pour réduire les problèmes.
Pour moi, un byte, c'est 8 bits, donc un entier entre 0 et 255.
Non. Attention à la terminologie différente d'un langage à l'autre !
Un "byte" est un terme anglais qui se traduit en français par "multiplet" et signifie "plus petit élément adressable".
En C. En Java, c'est un octet (signé), et aussi le "plus petit élément adressable".
Antoine
Pierre Maurette
Pierre Maurette écrivit dans news::
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent : - soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser des problèmes sur les machines où l'espace d'adressage réel atteint les limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits, pour supporter les pointeurs lointains. Ou 64 bits sur les machines actuelles.
Je me suis un peu fourvoyé, j'aurais dû écrire uintptr_t. Je ne vois pas(*) l'intérêt d'ailleurs d'un type signé pour cette utilisation. Sinon, dans mon idée, dans un contexte d'enseignement n'est pas un problème puisqu'il s'agit d'introduire des notions. Je me cite: "Je veux dire que même si le type n'est pas disponible sur telle ou telle implémentation, son existence montre la nécessité d'en créer un équivalent." Ensuite, effectivement, je ne sais pas trop à quel moment il est utile d'introduire les complications inhérentes à une mémoire segmentée/paginée dans un enseignement. J'imagine jamais le plus souvent, assez tôt pour un public très particulier. Enfin, en 2007.
(*) Ça veut juste dire "Je ne vois pas", et pas qu'il n'y a pas d'intérêt. C'est donc une question ;-)
PS: je souhaiterais vous contacter par mail. Pourriez-vous me communiquer votre adresse, la mienne est valide (et spammée, mais je filtre). Merci.
-- Pierre Maurette
Pierre Maurette écrivit dans news:mn.e32a7d71ef6e04a3.31483@laposte.net:
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent :
- soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser
des problèmes sur les machines où l'espace d'adressage réel atteint les
limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de
fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits,
pour supporter les pointeurs lointains. Ou 64 bits sur les machines
actuelles.
Je me suis un peu fourvoyé, j'aurais dû écrire uintptr_t. Je ne vois
pas(*) l'intérêt d'ailleurs d'un type signé pour cette utilisation.
Sinon, dans mon idée, dans un contexte d'enseignement n'est pas un
problème puisqu'il s'agit d'introduire des notions. Je me cite: "Je
veux dire que même si le type n'est pas disponible sur telle ou telle
implémentation, son existence montre la nécessité d'en créer un
équivalent."
Ensuite, effectivement, je ne sais pas trop à quel moment il est utile
d'introduire les complications inhérentes à une mémoire
segmentée/paginée dans un enseignement. J'imagine jamais le plus
souvent, assez tôt pour un public très particulier. Enfin, en 2007.
(*) Ça veut juste dire "Je ne vois pas", et pas qu'il n'y a pas
d'intérêt. C'est donc une question ;-)
PS: je souhaiterais vous contacter par mail. Pourriez-vous me
communiquer votre adresse, la mienne est valide (et spammée, mais je
filtre). Merci.
Pourquoi ne pas introduire rapidement le type intptr_t ?
Parce qu'il est trop souvent : - soit absent;
- soit trop petit : par exemple, étant obligatoirement signé, il peut poser des problèmes sur les machines où l'espace d'adressage réel atteint les limites physiques (32-64 Kio, 2-4 Gio), car il subtilise le bit de poids de fort;
- soit inutilement trop grand : genre 32 bits sur plateforme intel 16 bits, pour supporter les pointeurs lointains. Ou 64 bits sur les machines actuelles.
Je me suis un peu fourvoyé, j'aurais dû écrire uintptr_t. Je ne vois pas(*) l'intérêt d'ailleurs d'un type signé pour cette utilisation. Sinon, dans mon idée, dans un contexte d'enseignement n'est pas un problème puisqu'il s'agit d'introduire des notions. Je me cite: "Je veux dire que même si le type n'est pas disponible sur telle ou telle implémentation, son existence montre la nécessité d'en créer un équivalent." Ensuite, effectivement, je ne sais pas trop à quel moment il est utile d'introduire les complications inhérentes à une mémoire segmentée/paginée dans un enseignement. J'imagine jamais le plus souvent, assez tôt pour un public très particulier. Enfin, en 2007.
(*) Ça veut juste dire "Je ne vois pas", et pas qu'il n'y a pas d'intérêt. C'est donc une question ;-)
PS: je souhaiterais vous contacter par mail. Pourriez-vous me communiquer votre adresse, la mienne est valide (et spammée, mais je filtre). Merci.
-- Pierre Maurette
Pierre Maurette
[...]
In article , Pierre Maurette wrote:
Par exemple typedef unsigned char octet_t; typedef unsigned char uByte_t; typedef unsigned char sByte_t;
Mmm. J'eus bien vu typedef signed char sByte_t;
Mais c'est un avis personnel. :-)
Bien sûr. Les délices du Ctrl-C Ctrl-V. En fait, je n'ai jamais utilisé ces noms de type, parce qu'avant que je découvre les intN_t et toute la bande de <stdint.h>, dont les ...least... et ...fast..., je ne pratiquais pas le suffixage _t. Je faisais pire, j'utilisais la terminologie Intel/MASM/Microsoft API pour redéfinir mes types. On doit pouvoir retrouver de vieux messages de mon cru datant de mon arrivée sur fr.comp.lang.c et regrettant qu'il n'y ait pas d'équivalent en C des deux familles de types Pascal Object / Delphi. Merci à Marc, je vais cesser les monType_t. Je suis assez généreux en typedef. Il y a même des cas où je ne sais pas faire sans quelques typedef en "poupées russes". Y a-t-il un danger à partiquer ainsi ?
-- Pierre Maurette
[...]
In article <mn.e2fd7d7101ddd755.31483@laposte.net>, Pierre Maurette wrote:
Par exemple
typedef unsigned char octet_t;
typedef unsigned char uByte_t;
typedef unsigned char sByte_t;
Mmm. J'eus bien vu
typedef signed char sByte_t;
Mais c'est un avis personnel.
:-)
Bien sûr. Les délices du Ctrl-C Ctrl-V. En fait, je n'ai jamais utilisé
ces noms de type, parce qu'avant que je découvre les intN_t et toute la
bande de <stdint.h>, dont les ...least... et ...fast..., je ne
pratiquais pas le suffixage _t. Je faisais pire, j'utilisais la
terminologie Intel/MASM/Microsoft API pour redéfinir mes types. On doit
pouvoir retrouver de vieux messages de mon cru datant de mon arrivée
sur fr.comp.lang.c et regrettant qu'il n'y ait pas d'équivalent en C
des deux familles de types Pascal Object / Delphi.
Merci à Marc, je vais cesser les monType_t.
Je suis assez généreux en typedef. Il y a même des cas où je ne sais
pas faire sans quelques typedef en "poupées russes". Y a-t-il un danger
à partiquer ainsi ?
Par exemple typedef unsigned char octet_t; typedef unsigned char uByte_t; typedef unsigned char sByte_t;
Mmm. J'eus bien vu typedef signed char sByte_t;
Mais c'est un avis personnel. :-)
Bien sûr. Les délices du Ctrl-C Ctrl-V. En fait, je n'ai jamais utilisé ces noms de type, parce qu'avant que je découvre les intN_t et toute la bande de <stdint.h>, dont les ...least... et ...fast..., je ne pratiquais pas le suffixage _t. Je faisais pire, j'utilisais la terminologie Intel/MASM/Microsoft API pour redéfinir mes types. On doit pouvoir retrouver de vieux messages de mon cru datant de mon arrivée sur fr.comp.lang.c et regrettant qu'il n'y ait pas d'équivalent en C des deux familles de types Pascal Object / Delphi. Merci à Marc, je vais cesser les monType_t. Je suis assez généreux en typedef. Il y a même des cas où je ne sais pas faire sans quelques typedef en "poupées russes". Y a-t-il un danger à partiquer ainsi ?
-- Pierre Maurette
Pierre Maurette
[...]
Avec Java (qui garanti l'arithmétique en complément à deux), oui. En C, ce peut être parfois faux.
A noter, pas pour vous, Antoine, qui ne l'ignorez pas, que l'existence de types intN_t garantit l'arithmétique en complément à deux.
-- Pierre Maurette
[...]
Avec Java (qui garanti l'arithmétique en complément à deux), oui.
En C, ce peut être parfois faux.
A noter, pas pour vous, Antoine, qui ne l'ignorez pas, que l'existence
de types intN_t garantit l'arithmétique en complément à deux.
