Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

big/little endian

91 réponses
Avatar
David ROMAN
Est-il possible avoir un code en C capable de detecter le type de
processeur, en de lui forcer l'ecriture ou la lecture d'un fichier
binnaire en little ou big endian indifferement ???


Merci
David

10 réponses

6 7 8 9 10
Avatar
Gabriel Dos Reis
Pierre Maurette writes:

| Gabriel Dos Reis a écrit:
| [...]
| >La suggestion « mid » était une blague entre « little » et « big »
| >et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
| Pourtant,
| http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm

Là, tu m'apprends quelque chose (que le terme est réellement utilisé).
Merci.

-- Gaby
Avatar
Pierre Maurette
Gabriel Dos Reis a écrit:

Pierre Maurette writes:

| Gabriel Dos Reis a écrit:
| [...]
| >La suggestion « mid » était une blague entre « little » et « big »
| >et non quelque chose de sérieux de ma part. J'aurais dû mettre un smiley ;-p
| Pourtant,
| http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm

Là, tu m'apprends quelque chose (que le terme est réellement utilisé).
Merci.
J'ai remarqué que la littérature internet sur l'endianité donne

souvent lieu à un second degré assez US. Quand ces articles sont
repris au premier degré, ce qui est un des charmes et des défauts de
la toile, ça donne parfois des trucs hilarants. J'ai souvenir de
textes évoquant sérieusement le sexe des octets...
--
Pierre

Avatar
James Kanze
"Antoine Leca" writes:

|> En , James Kanze va escriure:
|> >>> Il y a des trucs du même genre dans le BIOS du PC IBM ou MS-DOS
|> >>> (je crois que la date-heure de la FAT est de ce genre-là, pas
|> >>> certain), mais cela n'a pas eu le même succès littéraire...

|> > C'est comme ça que fonctionnait le compilateur Microsoft. Jusqu'à
|> > un certain époque. Le résultat : on a la représentation des longs
|> > qui a changé d'une version à l'autre du compilateur.

|> ???

|> Tu parles bien de celui de Microsoft, donc à partir de la 4 (1986)
|> et après ? Je n'ai jamais vu quoi que ce soit d'approchant...

Je parle du compilateur qui a été vendu par Microsoft. Je sais que dans
la version 1.0, l'ordre des long était 3412. Puis, il y a eu longtemps
où je ne me suis pas servi. Je suis revenu (un peu) avec leur
compilateur VC++ 6.0. Et l'ordre des longs 1234. Alors, ils ont bien dû
changer à un moment ou un autre.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
James Kanze
Gabriel Dos Reis writes:

|> James Kanze writes:

|> | Gabriel Dos Reis writes:

|> | |> Marc Boyer writes:

|> | |> | James Kanze wrote:
|> | |> | > Pierre Maurette writes:
|> | |> | >|> De même pour le DWORD 0x12345678, écrit comme un DWORD:
|> | |> | >|> little endian: 78 56 34 12
|> | |> | >|> big endian: 12 34 56 78

|> | |> | > Ou 56 78 12 34, comme c'était le cas sur certains
|> | |> | > processeurs ou avec certains compilateurs (sur 8086, par
|> | |> | > exemple).

|> | |> | Il me semblait bien qu'il y avait un truc dans le genre,
|> | |> | et que le monde ne se divisait pas juste en little vs big.

|> | |> oui, il y a aussi les mid ;-)
|> | |> (PDP-family, VAX, ...)

|> | Ce sont des little big endian, ou les big little endian, selon que
|> | la nomenclature est big endian ou little endian.

|> La suggestion « mid » était une blague entre « little » et « big »
|> et non quelque chose de sérieux de ma part. J'aurais dû mettre un
|> smiley ;-p

Et tu crois que « little big endian » ou « big little endian » était
sérieux ? (En fait, je me rappelais un autre thread, dans le groupe C++,
où il était question des « long short » et des « short long ».)

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Gabriel Dos Reis
James Kanze writes:

[...]

| (En fait, je me rappelais un autre thread, dans le groupe C++,
| où il était question des « long short » et des « short long ».)

Le week-end dernier, lorsqu'on a voté pour « long long » pour C++ --
pour s'aligner avec C99 sur ce point -- il y a eu des suggestions de
nouveaux « type-specifiers » : « rather », « medium » et « very ».


very short int
rather long int
medium int

-- Gaby
Avatar
Charlie Gordon
"Gabriel Dos Reis" wrote in message
news:
James Kanze writes:

[...]

| (En fait, je me rappelais un autre thread, dans le groupe C++,
| où il était question des « long short » et des « short long ».)

Le week-end dernier, lorsqu'on a voté pour « long long » pour C++ --
pour s'aligner avec C99 sur ce point -- il y a eu des suggestions de
nouveaux « type-specifiers » : « rather », « medium » et « very ».


very short int
rather long int
medium int


C'était de l'humour ou de la lassitude ?

autres propositions :

shorter int
longest int
helluva long int
fucking short int (outside of th USA only)
int<64>

Chqrlie.

Avatar
James Kanze
Gabriel Dos Reis writes:

|> James Kanze writes:

|> [...]

|> | (En fait, je me rappelais un autre thread, dans le
|> | groupe C++, où il était question des « long short » et des « short
|> | long ».)

|> Le week-end dernier, lorsqu'on a voté pour « long long » pour C++ --
|> pour s'aligner avec C99 sur ce point -- il y a eu des suggestions de
|> nouveaux « type-specifiers » : « rather », « medium » et « very ».

|> very short int
|> rather long int
|> medium int

C'était de l'ironie, je suppose:-).

D'après ce que je sais, le comité C n'était pas ravi par « long long »
non plus. Il s'agissait d'adopter une pratique existante. En
l'occurance, une pratique existante seulement dans un milieu restreint
(Unix), mais apparamment, Unix compte plus que les autres.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Avatar
Gabriel Dos Reis
James Kanze writes:

| Gabriel Dos Reis writes:
|
| |> James Kanze writes:
|
| |> [...]
|
| |> | (En fait, je me rappelais un autre thread, dans le
| |> | groupe C++, où il était question des « long short » et des « short
| |> | long ».)
|
| |> Le week-end dernier, lorsqu'on a voté pour « long long » pour C++ --
| |> pour s'aligner avec C99 sur ce point -- il y a eu des suggestions de
| |> nouveaux « type-specifiers » : « rather », « medium » et « very ».
|
| |> very short int
| |> rather long int
| |> medium int
|
| C'était de l'ironie, je suppose:-).

Je crois que c'était une expression du dégoût général que cela
provoque. (Certains se sont même pincés le nez en votant ;-)).

| D'après ce que je sais, le comité C n'était pas ravi par « long long »
| non plus.

Mouais, m'enfin bon. Antoine a des histoires à raconter sur ce point --
si, mes souvenirs sont bons, je crois que la France a été le dernier à
lâcher du lest sur ce point (en troc avec un autre machin). Le comité
y tenait, visiblement il devait lui être important ou en être ravi.

-- Gaby
Avatar
Antoine Leca
En , Gabriel Dos Reis va escriure:
D'après ce que je sais, le comité C n'était pas ravi par « long long
» non plus.



Le comité n'était effectivement pas ravi, mais j'ai cru comprendre qu'il
s'agissait d'entériner des accords pré-existants, autrement dit quand j'y ai
mis les pieds en 98 les participants étaient las de précédentes discussions
sur le sujet.


Mouais, m'enfin bon. Antoine a des histoires à raconter sur ce point


Non, pas particulièrement d'histoires.

-- si, mes souvenirs sont bons, je crois que la France a été le
dernier à lâcher du lest sur ce point


Oui. Avec les Britanniques.
Et puis au CD2 on en a remis une couche quand on s'est aperçu de tous les
programmes qui craquaient parce que long n'était plus le plus long type,
d'où un tas de rustines un peu partout, modificateur z pour size_t et trucs
similaires.


(en troc avec un autre machin).


Mmmm, pas vraiment. Ils m'ont peut-être passé __STDC_ISO_10646__ pour
essayer de troquer, mais moi je ne l'ai jamais vu comme cela.
De même pour l'abandon du modèle (issu de C++) des UNC (uXXXX) pour un
modèle plus ouvert, permettant d'écrire des préprocesseurs croisés qui ne
connaissent pas exactement le jeu de caractères du source. Mais pour moi
c'était (et c'est toujours) de l'excellence technique, et j'ai la faiblesse
de croire que j'ai convaincu suffisament de membres.

C'est vrai que John m'a demandé de laisser tomber, avec l'argumentation que
j'explique ici (déjà trop vu, et cf. infra). Mais en fait nous n'avons pas
formellement retourné le vote au CD1, seulement au CD2 on a pas voté contre
parce que l'on s'est dit que cela n'apporterait rien. Et ce, en accord avec
les gens de C++ (qui en France sont beaucoup plus concernés par cela que les
utilisateurs de C: d'ailleurs l'AFNOR n'a toujours pas promulgué C99, à ce
que je sâche.)

Le comité y tenait, visiblement il devait lui être important ou en être
ravi.


Le comité nécessitait un moyen de forcer l'arithmétique sur 64 bits (sinon
C99 aurait perdu de l'intérêt, aurait raté le coche), sans renier aucun des
impératifs de compatibilité (donc obligatoirement int pouvait être 16 bits,
et il fallait pouvoir permettre que les compilos choisissent long=int pour
ne pas casser les programmes existants). En dehors de long long il n'y avait
guère d'autres solutions, l'invention d'un nouveau mot clé étant mal vu (cf.
_Bool, _Complex). _int64 n'était pas acceptable par la majorité du comité!
Et long long existait déjà.


Antoine


Avatar
Gabriel Dos Reis
"Antoine Leca" writes:

[...]

| > (en troc avec un autre machin).
|
| Mmmm, pas vraiment. Ils m'ont peut-être passé __STDC_ISO_10646__ pour
| essayer de troquer, mais moi je ne l'ai jamais vu comme cela.

:-)

| De même pour l'abandon du modèle (issu de C++) des UNC (uXXXX) pour un
| modèle plus ouvert, permettant d'écrire des préprocesseurs croisés qui ne
| connaissent pas exactement le jeu de caractères du source. Mais pour moi
| c'était (et c'est toujours) de l'excellence technique, et j'ai la faiblesse
| de croire que j'ai convaincu suffisament de membres.

« troc » ici n'était pas péjoratif. Vu le remue-ménage que tu as fait
avec time_t (ou struct tm?), les locales et autres j'ai eu
l'impression qu'à la fin on a cédé sur « long long » parce qu'ils
avaient déjà beaucoup reculé :-)
[Si mes souvenirs sont bons, il n'y avait que les états-uniens et les
japonnais qui tenaient férocement à long long, non ?]

| C'est vrai que John m'a demandé de laisser tomber, avec l'argumentation que
| j'explique ici (déjà trop vu, et cf. infra). Mais en fait nous n'avons pas
| formellement retourné le vote au CD1, seulement au CD2 on a pas voté contre
| parce que l'on s'est dit que cela n'apporterait rien. Et ce, en accord avec
| les gens de C++ (qui en France sont beaucoup plus concernés par cela que les
| utilisateurs de C: d'ailleurs l'AFNOR n'a toujours pas promulgué C99, à ce
| que je sâche.)

Hmm, je crois que j'ai vu passer un message sur ce sujet (il y a bien
longtemps) et j'avoue que je n'ai pas répondu (pensant à tort que tu
le ferais ;-)). On peut mettre ça  à l'ordre du jour de la prochaine
réunion AFNOR C/C++.

| > Le comité y tenait, visiblement il devait lui être important ou en être
| ravi.
|
| Le comité nécessitait un moyen de forcer l'arithmétique sur 64 bits (sinon
| C99 aurait perdu de l'intérêt, aurait raté le coche), sans renier aucun des
| impératifs de compatibilité (donc obligatoirement int pouvait être 16 bits,
| et il fallait pouvoir permettre que les compilos choisissent long=int pour
| ne pas casser les programmes existants). En dehors de long long il n'y avait
| guère d'autres solutions, l'invention d'un nouveau mot clé étant mal vu (cf.
| _Bool, _Complex). _int64 n'était pas acceptable par la majorité du comité!
| Et long long existait déjà.

Mais ils ont quand même inventé <inttypes.h> et <stdint.h>. Ils
auraient pu en faire un usage utile.

-- Gaby
6 7 8 9 10