En 40ead4dc$0$18118$, Alexandre BACQUART va escriure:
Antoine Leca wrote:
Je pense que l'on peut même avoir un DSP (>= 32 bits) avec sizeof(long) == sizeof(int) == 1.
Là, je ne te suis pas. L'opérateur sizeof retourne bien la taille en bytes non ?
Oui. Mais rien ne dit qu'un multiplet (byte, selon la commission de terminologie) doive avoir 8 bits, il peut aussi en avoir 32 (et sur un DSP, cela devient plausible, ce n'est pas le cas sur Unix ou Windows).
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Et du coup, ça explique pas mal de trucs confus pour moi ! Merci !
-- Tek
Antoine Leca wrote:
En 40ead4dc$0$18118$626a14ce@news.free.fr, Alexandre BACQUART va escriure:
Antoine Leca wrote:
Je pense que l'on peut même avoir un DSP (>= 32 bits) avec
sizeof(long) == sizeof(int) == 1.
Là, je ne te suis pas. L'opérateur sizeof retourne bien la taille en
bytes non ?
Oui. Mais rien ne dit qu'un multiplet (byte, selon la commission de
terminologie) doive avoir 8 bits, il peut aussi en avoir 32 (et sur un DSP,
cela devient plausible, ce n'est pas le cas sur Unix ou Windows).
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à
"octet"... va être dûr de m'enlever ça du crâne maintenant :)
Et du coup, ça explique pas mal de trucs confus pour moi ! Merci !
En 40ead4dc$0$18118$, Alexandre BACQUART va escriure:
Antoine Leca wrote:
Je pense que l'on peut même avoir un DSP (>= 32 bits) avec sizeof(long) == sizeof(int) == 1.
Là, je ne te suis pas. L'opérateur sizeof retourne bien la taille en bytes non ?
Oui. Mais rien ne dit qu'un multiplet (byte, selon la commission de terminologie) doive avoir 8 bits, il peut aussi en avoir 32 (et sur un DSP, cela devient plausible, ce n'est pas le cas sur Unix ou Windows).
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Et du coup, ça explique pas mal de trucs confus pour moi ! Merci !
-- Tek
Vincent Lefevre
Dans l'article <40eae3c3$0$18099$, Alexandre BACQUART écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> 100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17, Championnat International des Jeux Mathématiques et Logiques, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <40eae3c3$0$18099$626a14ce@news.free.fr>,
Alexandre BACQUART <tek512@hotmail.com> écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à
"octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est
évidemment une grosse erreur!
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/>
100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17,
Championnat International des Jeux Mathématiques et Logiques, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
... d'où l'intérêt de mon &255 initial; même si ça ne fera pas forcément ce que je veux au moins je n'explose pas mon tableau.
Oui, c'est bien ce que j'avais compris. :)
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> 100% validated (X)HTML - Acorn / RISC OS / ARM, free software, YP17, Championnat International des Jeux Mathématiques et Logiques, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Eric L
Le 6/07/04 14:58, dans <40eaa176$0$316$, « Richard Delorme » a écrit :
Pourquoi ? Je suis d'accord que 'é' n'est légal que si le caractère é existe dans dans l'ensemble étendu des caractères du source, et que cela dépend de l'implémentation, mais il me semble justement que ce caractère existe en UTF-8¹.
Oui é existe, bien sûr, en UTF-8. Et oui on peut avoir des architectures supportant le 'é' (au sens C), mais non ce n'est pas portable.
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int. Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous les bits d'un codage UTF-8 dans un int.
Exemple sur ma machine qui a la chance de supporter un int 32 bits et un codage Unicode 4 (certaines architectures sont encore à l'Unicode 3 ou même 2 et donc limitées à 65536 caractères) :
HAL3:~/tmp eric$ cat test.c #include <stdio.h> int main(void) { int c = 'é'; (void)printf("é : %#xn", c); return 0; } HAL3:~/tmp eric$ make test cc test.c -o test test.c:5:17: warning: multi-character character constant HAL3:~/tmp eric$ ./test é : 0xc3a9
Le caractère é est codé en UTF-8 sur 2 octets 0xc3 et 0xa9. Dans ce cas le codage entrera bien dans le int de ma machine. Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8) qui seront utilisés en UTF-8, et là le int ne sera pas forcément suffisant.
HAL3:~/tmp eric$ cat test2.c #include <stdio.h> int main(void) { int c = '賄'; (void)printf("賄 = %#xn", c); return 0; } HAL3:~/tmp eric$ make test2 cc test2.c -o test2 test2.c:4:17: warning: multi-character character constant HAL3:~/tmp eric$ ./test2 賄 = 0xe8b384
Pour ceux qui n'ont pas de lecteur de news UTF-8, ci-dessus se trouve un caractère chinois codé sur 24 bits (même si son codage Unicode est peut-être 16 bits). Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets (même si en Unicode 4 tout caractère tient sur 4 octets, et 2 octets pour l'Unicode 3).
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 6/07/04 14:58, dans <40eaa176$0$316$7a628cd7@news.club-internet.fr>,
« Richard Delorme » <abulmo@nospam.fr> a écrit :
Pourquoi ? Je suis d'accord que 'é' n'est légal que si le caractère é
existe dans dans l'ensemble étendu des caractères du source, et que cela
dépend de l'implémentation, mais il me semble justement que ce caractère
existe en UTF-8¹.
Oui é existe, bien sûr, en UTF-8. Et oui on peut avoir des architectures
supportant le 'é' (au sens C), mais non ce n'est pas portable.
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte
character" entre les "single-quote". Si é est écrit sur plusieurs bytes,
cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8
d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int.
Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous
les bits d'un codage UTF-8 dans un int.
Exemple sur ma machine qui a la chance de supporter un int 32 bits et un
codage Unicode 4 (certaines architectures sont encore à l'Unicode 3 ou même
2 et donc limitées à 65536 caractères) :
HAL3:~/tmp eric$ cat test.c
#include <stdio.h>
int main(void)
{
int c = 'é';
(void)printf("é : %#xn", c);
return 0;
}
HAL3:~/tmp eric$ make test
cc test.c -o test
test.c:5:17: warning: multi-character character constant
HAL3:~/tmp eric$ ./test
é : 0xc3a9
Le caractère é est codé en UTF-8 sur 2 octets 0xc3 et 0xa9. Dans ce cas le
codage entrera bien dans le int de ma machine. Mais si j'utilise des
caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la
limite est de 6 en UTF-8) qui seront utilisés en UTF-8, et là le int ne sera
pas forcément suffisant.
HAL3:~/tmp eric$ cat test2.c
#include <stdio.h>
int main(void)
{
int c = '賄';
(void)printf("賄 = %#xn", c);
return 0;
}
HAL3:~/tmp eric$ make test2
cc test2.c -o test2
test2.c:4:17: warning: multi-character character constant
HAL3:~/tmp eric$ ./test2
賄 = 0xe8b384
Pour ceux qui n'ont pas de lecteur de news UTF-8, ci-dessus se trouve un
caractère chinois codé sur 24 bits (même si son codage Unicode est peut-être
16 bits). Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets (même
si en Unicode 4 tout caractère tient sur 4 octets, et 2 octets pour
l'Unicode 3).
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une
architecture avec des int de 16 bits.
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie
du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce
que permet le int standard. C'est pour cela que le wchar_t ont été inventé
et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 6/07/04 14:58, dans <40eaa176$0$316$, « Richard Delorme » a écrit :
Pourquoi ? Je suis d'accord que 'é' n'est légal que si le caractère é existe dans dans l'ensemble étendu des caractères du source, et que cela dépend de l'implémentation, mais il me semble justement que ce caractère existe en UTF-8¹.
Oui é existe, bien sûr, en UTF-8. Et oui on peut avoir des architectures supportant le 'é' (au sens C), mais non ce n'est pas portable.
D'après la norme 6.4.4.4 #2, on doit avoir un ou plusieurs "multibyte character" entre les "single-quote". Si é est écrit sur plusieurs bytes, cela ne semble pas un problème.
Si cela pose un problème car un caractère qui utilise plusieurs octets (le 8 d'UTF-8 c'est pour octet) peut très bien déborder d'un char ou d'un int. Mais bien sûr on peut trouver des architectures où on arrive à rentrer tous les bits d'un codage UTF-8 dans un int.
Exemple sur ma machine qui a la chance de supporter un int 32 bits et un codage Unicode 4 (certaines architectures sont encore à l'Unicode 3 ou même 2 et donc limitées à 65536 caractères) :
HAL3:~/tmp eric$ cat test.c #include <stdio.h> int main(void) { int c = 'é'; (void)printf("é : %#xn", c); return 0; } HAL3:~/tmp eric$ make test cc test.c -o test test.c:5:17: warning: multi-character character constant HAL3:~/tmp eric$ ./test é : 0xc3a9
Le caractère é est codé en UTF-8 sur 2 octets 0xc3 et 0xa9. Dans ce cas le codage entrera bien dans le int de ma machine. Mais si j'utilise des caractères chinois par exemple, ce n'est plus 2 octets, mais 3 ou 4 (la limite est de 6 en UTF-8) qui seront utilisés en UTF-8, et là le int ne sera pas forcément suffisant.
HAL3:~/tmp eric$ cat test2.c #include <stdio.h> int main(void) { int c = '賄'; (void)printf("賄 = %#xn", c); return 0; } HAL3:~/tmp eric$ make test2 cc test2.c -o test2 test2.c:4:17: warning: multi-character character constant HAL3:~/tmp eric$ ./test2 賄 = 0xe8b384
Pour ceux qui n'ont pas de lecteur de news UTF-8, ci-dessus se trouve un caractère chinois codé sur 24 bits (même si son codage Unicode est peut-être 16 bits). Mais on peut en trouver qui ont un codage UTF-8 sur 5 octets (même si en Unicode 4 tout caractère tient sur 4 octets, et 2 octets pour l'Unicode 3).
On aurait le même problème avec d'autres encodages comme l'UTF-32 et une architecture avec des int de 16 bits.
Donc quel est le problème avec 'é' et UTF-8 ?
Le problème n'est pas simplement sur le é, mais sur tout caractère qui dévie du jeu de base et qui peut, à priori, occuper beaucoup plus de place que ce que permet le int standard. C'est pour cela que le wchar_t ont été inventé et qu'il a une taille assez grande pour pouvoir représenter tout caractère.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Eric Lévénez
Le 6/07/04 14:16, dans <20040706121541$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <BD1055EB.54C7%, Eric Lévénez écrit:
Le 6/07/04 9:10, dans <40ea4fee$0$306$, « Richard Delorme » a écrit :
Rappel : en C, 'é' est de type int.
Rappel : 'é' est illégal, par exemple, sur une architecture utilisant l'UTF-8.
Pas forcément.
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que certaines plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant sur un int. Mais ce n'est pas une certitude, ce n'est donc pas portable, c'est donc illégal (à mon point de vue), même si cela ne l'est pas explicitement dans la norme C.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 6/07/04 14:16, dans <20040706121541$5f69@vinc17.org>, « Vincent Lefevre »
<vincent+news@vinc17.org> a écrit :
Dans l'article <BD1055EB.54C7%news@levenez.com>,
Eric Lévénez <news@levenez.com> écrit:
Le 6/07/04 9:10, dans <40ea4fee$0$306$7a628cd7@news.club-internet.fr>,
« Richard Delorme » <abulmo@nospam.fr> a écrit :
Rappel : en C, 'é' est de type int.
Rappel : 'é' est illégal, par exemple, sur une architecture utilisant
l'UTF-8.
Pas forcément.
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que certaines
plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant sur un int. Mais
ce n'est pas une certitude, ce n'est donc pas portable, c'est donc illégal
(à mon point de vue), même si cela ne l'est pas explicitement dans la norme
C.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 6/07/04 14:16, dans <20040706121541$, « Vincent Lefevre » <vincent+ a écrit :
Dans l'article <BD1055EB.54C7%, Eric Lévénez écrit:
Le 6/07/04 9:10, dans <40ea4fee$0$306$, « Richard Delorme » a écrit :
Rappel : en C, 'é' est de type int.
Rappel : 'é' est illégal, par exemple, sur une architecture utilisant l'UTF-8.
Pas forcément.
Oui, c'est pour cela que j'ai dit "par exemple", pour indiquer que certaines plates-formes pouvaient avoir de l'UTF-8 et un 'é' tenant sur un int. Mais ce n'est pas une certitude, ce n'est donc pas portable, c'est donc illégal (à mon point de vue), même si cela ne l'est pas explicitement dans la norme C.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Alexandre BACQUART
Vincent Lefevre wrote:
Dans l'article <40eae3c3$0$18099$, Alexandre BACQUART écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Mon confusion vient précisément de là (et du fait que byte est utilisé un peu partout dans ce sens).
-- Tek
Vincent Lefevre wrote:
Dans l'article <40eae3c3$0$18099$626a14ce@news.free.fr>,
Alexandre BACQUART <tek512@hotmail.com> écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à
"octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est
évidemment une grosse erreur!
Mon confusion vient précisément de là (et du fait que byte est utilisé
un peu partout dans ce sens).
Dans l'article <40eae3c3$0$18099$, Alexandre BACQUART écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Mon confusion vient précisément de là (et du fait que byte est utilisé un peu partout dans ce sens).
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre BACQUART wrote:
C'est quoi un "byte" d'après la norme ?
Le plus petit élément mémoire adressable >= à 8 bits.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Alexandre BACQUART <tek512@hotmail.com> wrote:
C'est quoi un "byte" d'après la norme ?
Le plus petit élément mémoire adressable >= à 8 bits.
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Le plus petit élément mémoire adressable >= à 8 bits.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre BACQUART wrote:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
octet/octet = élément mémoire d'exactement 8 bits. byte/multiplet = plus petit élément mémoire adressable >= 8 bits
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Alexandre BACQUART <tek512@hotmail.com> wrote:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à
"octet"... va être dûr de m'enlever ça du crâne maintenant :)
octet/octet = élément mémoire d'exactement 8 bits.
byte/multiplet = plus petit élément mémoire adressable >= 8 bits
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
octet/octet = élément mémoire d'exactement 8 bits. byte/multiplet = plus petit élément mémoire adressable >= 8 bits
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
C'est pour ça que je regarde les films en VO...
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+news@vinc17.org> wrote:
Au passage, le K&R en français a traduit ça par "octet", ce qui est
évidemment une grosse erreur!
C'est pour ça que je regarde les films en VO...
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
C'est pour ça que je regarde les films en VO...
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Jean-Noël Mégoz
"Alexandre BACQUART" a écrit dans le message de news:40eaea3f$0$18110$
Vincent Lefevre wrote:
Dans l'article <40eae3c3$0$18099$, Alexandre BACQUART écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
"Alexandre BACQUART" <tek512@hotmail.com> a écrit dans le message de
news:40eaea3f$0$18110$626a14ce@news.free.fr...
Vincent Lefevre wrote:
Dans l'article <40eae3c3$0$18099$626a14ce@news.free.fr>,
Alexandre BACQUART <tek512@hotmail.com> écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à
"octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est
évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de
"octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD
de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même
ici, la taille du byte peut changer ?
"Alexandre BACQUART" a écrit dans le message de news:40eaea3f$0$18110$
Vincent Lefevre wrote:
Dans l'article <40eae3c3$0$18099$, Alexandre BACQUART écrit:
Depuis le temps que j'utilise ce mot en pensant qu'il fait référence à "octet"... va être dûr de m'enlever ça du crâne maintenant :)
Au passage, le K&R en français a traduit ça par "octet", ce qui est évidemment une grosse erreur!
Dans un contexte de programmation, byte n'est peut-être pas équivalent de "octet", mais d'un point de vue matériel, une RAM de 128 megabytes ou un DD de 40 gigabytes font bien 128 megaoctets et 40 gigaoctets, non ? Ou même ici, la taille du byte peut changer ?
