[F] High-tech » Histoires de boutiens - Page 1

Ce sujet est issu d'une discussion ayant dérivé sur deux thèmes distincts. Pour vous rendre sur le sujet d'origine, merci de cliquer sur ce lien

j'ai envie de tuer celui qui a inventé le mot little endian

//Write little endian file size
outFile.write((length       )&0xff);
outFile.write((length >>>  8)&0xff);
outFile.write((length >>> 16)&0xff);
outFile.write((length >>> 24)&0xff);

>>> ?

Tue plutôt le créateur du C, ou mieux encore, celui qui a décrété que c'était un langage portable.

Je vois mal comment régler ce problème, quel que soit le langage.

Mettre des fonctions d'I/O indépendantes de l'implémentation dans les libs standards, comme c'est le cas en C# par exemple.

Faudrait que je vous montre mes macros... mais on n'est pas assez intimes pour cela :/

Kochise

T'inquiète, on doit avoir à peu près les mêmes

Ximoon (./10987) :
>>> ?

Ben, décalage à droite sans étendre le msb.

squalyl (./10986) :
j'ai envie de tuer celui qui a inventé le mot little endian

//Write little endian file size
outFile.write((length       )&0xff);
outFile.write((length >>>  8)&0xff);
outFile.write((length >>> 16)&0xff);
outFile.write((length >>> 24)&0xff);

tu pourrais te faire une fonction, quand même


(mais )

Tiens il me semblait que >>> était carrément pas portable (enfin pas supporté par les compilos). De toute façon tu n'as pas besoin de ça, l'opérateur habituel va très bien.

unsigned i = 4;
while (i--) {
    outFile.write(length & 255);
    length >>= 8;
}

#include <arpa/inet.h>
uint32_t htonl(uint32_t hostlong);
uint16_t htons(uint16_t hostshort);
uint32_t ntohl(uint32_t netlong);
uint16_t ntohs(uint16_t netshort);

sont tes amis

">>>" n'est pas dans la liste des opérateurs standard du C ; ">>" peut ou non étendre le MSB lorsqu'il est appliqué à un nombre signé, ça dépend de l'implémentation.

Je sais pas pour la portabilité... Il me semblait aussi que c'était plutôt du Javascript (cross : OK)
(les masques en décimal, çay mal )
(et c'est étrange de choisir un while alors que i est utilisé seulement dans la bouche )

Brunni (./10995) :
Tiens il me semblait que >>> était carrément pas portable (enfin pas supporté par les compilos).

Tout dépend du langage : si c'est du Java, ca l'est.

Zerosquare (./10990) :
Mettre des fonctions d'I/O indépendantes de l'implémentation dans les libs standards, comme c'est le cas en C# par exemple.

C'est aussi le cas en java, mais comme tu peux lire/recevoir des données qui ont été générées par des programmes non java, le problème existe quand même

Bref, c'est indémerdable.

squalyl (./10986) :
j'ai envie de tuer celui qui a inventé le mot little endian

Jonathan Swift ? le pauvre (enfin il est déjà mort depuis trois siècles de toute façon )

Non, c'est quand même mieux de pouvoir s'affranchir de ce problème pour ses propres programmes...

Sally :

pour info c'était du java

(int b) throws IOException; // ... }Auquel cas le masque « &0xFF » est inutile :public abstract class OutputStream implements Closeable, Flushable { /** * Writes the specified byte to this output stream. The general * contract for <code>write</code> is that one byte is written * to the output stream. The byte to be written is the eight * low-order bits of the argument <code>b</code>. The 24 * high-order bits of <code>b</code> are ignored. * <p> * Subclasses of <code>OutputStream</code> must provide an * implementation for this method. * * @param b the <code>byte</code>. * @exception IOException if an I/O error occurs. In particular, * an <code>IOException</code> may be thrown if the * output stream has been closed. */ public abstract void write

Si c'est du java alors tu peux aussi utiliser les "nio" la classe ByteBuffer peut fonctionner soit en bigendian soit en littleendian.

squalyl (./11003) :
pour info c'était du java

Alors souffre!

Zerosquare (./10992) :
T'inquiète, on doit avoir à peu près les mêmes

Pas forcément, regarde :

  /* Endian conversion, Kochise's way */

  #define B2L_08(t)         ((t)&0x0FF)
  #define B2L_16(t)         (B2L_08((t)>>8))|(B2L_08((t)&0x000000FF))<<8
  #define B2L_32(t)         (B2L_16((t)>>16))|(B2L_16((t)&0x0000FFFF))<<16
  #define B2L_64(t)         (B2L_32((t)>>32))|(B2L_32((t)&0xFFFFFFFF))<<32

  #define L2B_08(t)         B2L_08(t)
  #define L2B_16(t)         B2L_16(t)
  #define L2B_32(t)         B2L_32(t)
  #define L2B_64(t)         B2L_64(t)

Ce qui donne :

//Write little endian file size
outFile.write(B2L_32(length));

"Magie !" (c) Jasmine

Kochise

Intéressant, mais je préfère les macros qui sont indépendantes de l'endianness de la machine sur laquelle on compile, comme ça c'est vraiment portable

(ceci dit, on devrait créer un nouveau sujet)

./11007 Et ils servent à quoi tous ces masques ?

  /* Endian conversion, Kochise's way (enfin presque) */

  #define B2L_08(t)         ((t)&0x0FF)
  #define B2L_16(t)         (B2L_08((t)>>8)|B2L_08(t)<<8)
  #define B2L_32(t)         (B2L_16((t)>>16)|B2L_16(t)<<16)
  #define B2L_64(t)         (B2L_32((t)>>32)|B2L_32(t)<<32)

  #define L2B_08(t)         B2L_08(t)
  #define L2B_16(t)         B2L_16(t)
  #define L2B_32(t)         B2L_32(t)
  #define L2B_64(t)         B2L_64(t)

Ça ne donne pas la même chose ?

Zerosquare (./11008) :
Intéressant, mais je préfère les macros qui sont indépendantes de l'endianness de la machine sur laquelle on compile, comme ça c'est vraiment portable

Certes, mais comme K&R n'y ont pas pensés, ce n'est pas inclus dans le langage et il faut le faire à-la-mano. Dans ma boite à outils, j'ai toute une chiée de macros du même genre afin que ce soit factorisable par le compilateur...

RHJPP (./11009) :
./11007 Et ils servent à quoi tous ces masques ? [...] Ça ne donne pas la même chose ?

Essaye, tu vas voir (c'est à cause de la récursion des macros qui est ensuite factorisée par le compilateur -les décalages sont simplifiés- ça évite la collision des bits à cause de la fonction OU logique )

L'avantage, t'y colles n'importe quoi, du __int8 au __int64 sans avoir à caster, c'est implicite !

Kochise

J'aurai plutôt fait comme ça moi:

#define ENDIANNESS_SWAP_08(t)         ((t)&0x0FF)
#define ENDIANNESS_SWAP_16(t)         ((B2L_08((t)>>8))|(B2L_08((t)&0x000000FF))<<8)
#define ENDIANNESS_SWAP_32(t)         ((B2L_16((t)>>16))|(B2L_16((t)&0x0000FFFF))<<16)
#define ENDIANNESS_SWAP_64(t)         ((B2L_32((t)>>32))|(B2L_32((t)&0xFFFFFFFF))<<32)

#ifdef BIG_ENDIAN
#define TO_BE_08(n) (n)
#define TO_BE_16(n) (n)
#define TO_BE_32(n) (n)
#define TO_BE_64(n) (n)

#define TO_LE_08(n) ENDIANNESS_SWAP_08(n)
#define TO_LE_16(n) ENDIANNESS_SWAP_16(n)
#define TO_LE_32(n) ENDIANNESS_SWAP_32(n)
#define TO_LE_64(n) ENDIANNESS_SWAP_64(n)
#else
#ifndef LITTLE_ENDIAN
#define LITTLE_ENDIAN
#endif
#define TO_BE_08(n) ENDIANNESS_SWAP_08(n)
#define TO_BE_16(n) ENDIANNESS_SWAP_16(n)
#define TO_BE_32(n) ENDIANNESS_SWAP_32(n)
#define TO_BE_64(n) ENDIANNESS_SWAP_64(n)

#define TO_LE_08(n) (n)
#define TO_LE_16(n) (n)
#define TO_LE_32(n) (n)
#define TO_LE_64(n) (n)
#endif

C'est beaucoup plus propre.
En plus tu as oublié les parenthèses autour de tes macro (je les ai rajouté), donc elles ne fonctionnent pas correctement dans tous les cas d'utilisation…

Nan c'est pas plus propre (ton code est plus long et donc plus difficilement maintenable) puisque dans un cas comme dans l'autre, qu'importe l'endianesse de la machine, ça marche, pas besoin de compilation conditionnelle. Pour les parenthèses, en principe tu n'en as pas besoin (sauf peut être _64(t)) car c'est compris de façon récursif dans les appels de macro (regarde comment (t) est systématiquement protégé entre parenthèses)

Kochise

B2L_16(32768) + B2L_16(32768) donne donc le bon résultat ? (256)

Ton truc est crade parce que tu vas utiliser "B2L_" ou bien "L2B_" quelle que soit l'architecture de la machine sur le code est compilé… Ce que font tes macros c'est permuter l'odre des octets, et rien d'autre, y'a donc pas lieu de les nommer B2L ou L2B car c'est juste faux…

./11010 Je viens de tester avec ./11009 et ça fonctionne très bien...