sorte de self modifying code en C - Page 3

"GCC avait un défaut et que l'extension n'était qu'un work-around" => Ce qui est vrai.
"et qu'il vaudrait mieux le corriger" => Ce qui est vrai aussi.
Après, que ce soit possible ou non c'est un autre problème.
Enfin, bon c'est vrai qu'on ne va pas pinailler sur une tournure de phrase

Mais non, GCC n'a pas de défaut de ce point de vue-là Tu ne peux pas reprocher à ton cerveau de ne pas être connecté au proc de ton ordinateur, tu ne peux pas reprocher à GCC de ne pas savoir résoudre une question indécidable...

>Pollux: C'est n'importe quoi, ce prétexte !
Non, je prefere laisser un warning que faire ce genre de "pseudo"
correction. De toute facon, je corriger les warnings en meme temps
que les erreurs, donc j'en ai suffisament peu pour que ca ne soit pas
un probleme de les laisser.
Il est possible que si j'en avais des centaines comme celui-ci
je mette en place ce genre de correction, mais ce n'est pas le cas.

>qd le type qui écrit la boucle se dit que de toute façon il n'y aura pas d'overflow
Surement. Et ca fait une vulnerabilite de plus dans le programme.

>spectras: Plus je multiplie les approches, plus je suis impressionné par les capacités d'optimisation de gcc.
Moi c'est le contraire, et je suis de plus en plus decu par ces
capacites d'optimisations.

>Moi qui pensais que le c m'enlèverait la possibilité de réordonnancer mes instructions...
C'est rarement utilise de facon optimale.

>sauf que si c'est de cet ordre, du peux aussi décaler tes indices, ce qui est quand meme plus simple.
Non je ne peux pas. Je n'ai aucun contraire sur les structures de donnees
qui me sont imposes.

>Pollux: Et au contraire, c'est mieux d'avoir un truc qui attire l'attention qu'un truc qui pourrait vouloir dire autre chose ("int x=0;" pourrait vouloir dire n'importe quoi).
Disons perso, l'ordre serait:
Ignorer le warning
int x= x;
int x= valeur_bidon;

>donc un truc "voyant" comme "int x=x;"
C'est pas si voyant comme truc...

>J'avoue que ces histoires de conversions signed/unsigned sont un point assez casse-gueule et platform-dependent...
Pas tant que ca. Faut pas exagerer.

>Ca redevient portable si on suppose que n est castable en long... (n<=LONG_MAX)
unsigned int i, n;
...
int j = (long) i - n/2;
Ne marche pas dans le cas ou la representation des signes n'est pas le complement a 2, et si int=long.
Mais il faut aussi ajouter que les specs du pb ne sont pas tres claires.
Tu supposes aussi que UINT_MAX <= INT_MAX*2...
Or ca peut etre faux.
Pour resoudre ce probleme, il faudrait toutes les donnees.

PpHd :
>Pollux: C'est n'importe quoi, ce prétexte !
Non, je prefere laisser un warning que faire ce genre de "pseudo"
correction. De toute facon, je corriger les warnings en meme temps
que les erreurs, donc j'en ai suffisament peu pour que ca ne soit pas un probleme de les laisser.

Beuh? Mais il n'y a aucune correction à faire, à part de dire que c'est bien volontaire...

>qd le type qui écrit la boucle se dit que de toute façon il n'y aura pas d'overflow Surement. Et ca fait une vulnerabilite de plus dans le programme.

Exactement ce que je dis. C'est pour ça que c'est important de corriger ces erreurs-là.

>Pollux: Et au contraire, c'est mieux d'avoir un truc qui attire l'attention qu'un truc qui pourrait vouloir dire autre chose ("int x=0;" pourrait vouloir dire n'importe quoi).
Disons perso, l'ordre serait:
Ignorer le warning
int x= x; int x= valeur_bidon;

Laisser un warning, c'est qd même assez chiant... Ca va bien si c très temporaire (le tps de qques debugs), mais si ça doit rester, bof.

>donc un truc "voyant" comme "int x=x;" C'est pas si voyant comme truc...

Ca saute aux yeux que y a un truc bizarre...

>J'avoue que ces histoires de conversions signed/unsigned sont un point assez casse-gueule et platform-dependent... Pas tant que ca. Faut pas exagerer.

Si si. Sauf que en pratique, on a souvent de la chance : on travaille sur des plateformes 16/32/32 donc même si on fait des suppositions hasardeuses, ça marche à peu près. En plus le x86 est insensible aux overflows dans les additions, et la plupart des compilos sont soit trop primaires pour utiliser l'undefined behaviour en cas d'overflow, soit proposent des options pour lui donner un sens bien défini. Donc en pratique, actuellement, ça marche 99% du temps. Mais ce n'est pas du tout garanti par le standard C. Le pire, c'est que ça peut faire des trous de sécurité sur certaines architectures et pas sur d'autres...

>Ca redevient portable si on suppose que n est castable en long... (n<=LONG_MAX)
unsigned int i, n;
...
int j = (long) i - n/2; Ne marche pas dans le cas ou la representation des signes n'est pas le complement a 2, et si int=long.

J'ai dit clairement que ça ne marchait que si int<long (sinon tu remplaces long par long long). Tu vois que c'est pas si simple que ça : ce code ce comporte différemment en 16/32/32 et en 16/32/64...

Mais il faut aussi ajouter que les specs du pb ne sont pas tres claires. Tu supposes aussi que UINT_MAX <= INT_MAX*2...

Oui, je suppose que n<=INT_MAX*2 et n<=LONG_MAX... (si je n'impose pas de contrainte sur 'n', je ne peux rien faire de manière portable : en effet je n'ai aucune garantie que n sera castable en 'long' sans perte)

Or ca peut etre faux. Pour resoudre ce probleme, il faudrait toutes les donnees.

Oui, évidemment... Je voulais juste donner à spectras un exemple où le décalage d'indice dont il parlait ne marche clairement pas

>la plupart des compilos sont soit trop primaires pour utiliser l'undefined behaviour en cas d'overflow,
Je serais content que tu me sortes un couple systeme/compilo sur lequel l'undefined behavior apparait.
Ou carement un couple systeme/compilo qui balance des exceptions si on lit une variable non-initialisee.

>Ca saute aux yeux que y a un truc bizarre...
int a=1, b=2, c=3, d=4, e=e, f=6;
Ca saute aux yeux, oui...

>on travaille sur des plateformes 16/32/32
Je travaille sur 16/16/32/64, 16/32/32/64, 16/32/64/64 perso.
(Recherche desesperement architecture ou long long = 128 bits).
Ce que je voulais dire est que en general le n a ete restreint a un intervale plus petit (genre 0 a INT_MAX/2).
Alors la, la convertion est simplifiee.

>(sinon tu remplaces long par long long)
Et les architecture ou int=long=long long
Et les alphas ? (non, je deconne, int =32, long = long long = 64).

>si je n'impose pas de contrainte sur 'n', je ne peux rien faire de manière portable :
Si, mais ca devient lourd (enfin je veux dire, aussi loin que l'on peut).

>Laisser un warning, c'est qd même assez chiant...
Je prefere le laisser plutot que de faire ce genre de corrections.

PpHd :
>la plupart des compilos sont soit trop primaires pour utiliser l'undefined behaviour en cas d'overflow, Je serais content que tu me sortes un couple systeme/compilo sur lequel l'undefined behavior apparait.

GCC, d'après ce que dit Kevin. Non pas qu'il balance une exception pour le plaisir, mais il pourrait balancer des résultats faux.

Par exemple unsigned int uintg=intg*intg; => abs((int)uintg)=uintg...
Mais je viens d'essayer, et j'arrive pas à le reproduire : c'est p-ê Kevin qui pipotait... En tout cas si c pas le cas alors ça peut rendre un prog subtilement faux.

Ou carement un couple systeme/compilo qui balance des exceptions si on lit une variable non-initialisee.

Connais pas, ça doit être plus rare, mais il doit bien y avoir un processeur exotique que plus personne n'utilise non?

>Ca saute aux yeux que y a un truc bizarre...
int a=1, b=2, c=3, d=4, e=e, f=6; Ca saute aux yeux, oui...

... Tu peux _aussi_ le mettre sur une ligne séparée...

>on travaille sur des plateformes 16/32/32 Je travaille sur 16/16/32/64, 16/32/32/64, 16/32/64/64 perso.

Bah oui, mais le codeur Linux moyen ne le fait pas forcément.. Et ton 16/16/32, c'est autre chose que le 68k ?

(Recherche desesperement architecture ou long long = 128 bits).

Ca ne sert pas à gd chose, à part éventuellement si les pointeurs font 128 bits, mais je doute que ça existe

>si je n'impose pas de contrainte sur 'n', je ne peux rien faire de manière portable : Si, mais ca devient lourd (enfin je veux dire, aussi loin que l'on peut).

Oui

>Laisser un warning, c'est qd même assez chiant... Je prefere le laisser plutot que de faire ce genre de corrections.

chacun son truc ^^

>GCC, d'après ce que dit Kevin.
Sur quel systeme, quelle version ?

>Et ton 16/16/32, c'est autre chose que le 68k ?
Nan, le 68000.

>Ca ne sert pas à gd chose, à part éventuellement si les pointeurs font 128 bits, mais je doute que ça existe
Tu dois confondre la...
En quoi l'espace adressage et les donnees manipules coincident-ils ?
uint128_t x, y;
x = 7; y = 1<<127 / 7;
En quoi c'est extraordinaire?
Surtout que pour factoriser des nombres ca serait bien sympa d'aller jusqu'a 128.

PpHd :
>GCC, d'après ce que dit Kevin. Sur quel systeme, quelle version ?

Demande-lui

>Et ton 16/16/32, c'est autre chose que le 68k ? Nan, le 68000.

OK, mais la plupart des progs destinés aux ordinateurs avec plusieurs Mo de RAM supposent que int>=32bits.

>Ca ne sert pas à gd chose, à part éventuellement si les pointeurs font 128 bits, mais je doute que ça existe Tu dois confondre la...

Non, je crois pas

En quoi l'espace adressage et les donnees manipules coincident-ils ?
uint128_t x, y;
x = 7; y = 1<<127 / 7;
En quoi c'est extraordinaire? Surtout que pour factoriser des nombres ca serait bien sympa d'aller jusqu'a 128.

C'est extraordinaire en ce sens que ce serait _inutile_ de changer le long long pour faire 128 bits, en revanche introduire un long long long ou un __int128__ me paraîtrait utile. Donc un long long de plus de 64 bits, bof si on n'a pas un adressage sur plus de 64 bits.

Le long long ne fait pas 64 bits! Il est au minimum egal a 64 bits! Et il n'est meme pas sur que long long soit le type d'entier le plus grand representable par la machine. Si tu veux un type qui fasse 64 bits, utilise uint64_t ou int64_t ! Si tu melange pas les chaussettes et les slips, je ne sais pas ce que tu fais la.

> OK, mais la plupart des progs destinés aux ordinateurs avec plusieurs Mo de RAM supposent que int>=32bits.
Pas les bons programmes

>Demande-lui
Il est pas la.

PpHd :
>Ca redevient portable si on suppose que n est castable en long... (n<=LONG_MAX)
unsigned int i, n;
...
int j = (long) i - n/2;
Ne marche pas dans le cas ou la representation des signes n'est pas le complement a 2, et si int=long.
Mais il faut aussi ajouter que les specs du pb ne sont pas tres claires.
Tu supposes aussi que UINT_MAX <= INT_MAX*2...
Or ca peut etre faux. Pour resoudre ce probleme, il faudrait toutes les donnees.

Il vaut mieux utiliser long long que long pour ça. Marche avec GCC sous toutes les plateformes: long long fait 64 bits minimum, int fait 32 bits maximum sous toutes les architectures de GCC, le plus grand est I32LP64 (abrégé généralement LP64).

Et GCC ne permet les long long 128 bits que depuis très peu de temps (limitation due à la nécessité de pouvoir cross-compiler à partir d'un host 32 bits), et aucune architecture ne les utilise pour des raisons de compatibilité.

Et pour les débordements signés, le comportement est non-spécifié, donc il se peut très bien que ça marche par hasard, mais rien n'est garanti dans ce sens (sauf avec -fwrapv qui n'existe que depuis GCC 3.4).

Sauf que en pratique, même avec GCC, ça marche, non? (sauf éventuellement pour les divisions où ça doit être plus difficile, mais ça s'appelle chercher les ennuis, ça)

PpHd :
Le long long ne fait pas 64 bits! Il est au minimum egal a 64 bits! Et il n'est meme pas sur que long long soit le type d'entier le plus grand representable par la machine. Si tu veux un type qui fasse 64 bits, utilise uint64_t ou int64_t ! Si tu melange pas les chaussettes et les slips, je ne sais pas ce que tu fais la.

rogntudju, je ne parle pas de supposer que sizeof(long long)=8, mais je dis juste qu'il n'y a aucun _intérêt_ pour une architecture à avoir sizeof(long long)=16, sauf si le compilateur est mal foutu et ne supporte pas d'avoir un type entier supplémentaire... Mais dans ce cas y a des chances pour que les entiers 128 bits ne soient pas supportés non plus ^^

> OK, mais la plupart des progs destinés aux ordinateurs avec plusieurs Mo de RAM supposent que int>=32bits.
Pas les bons programmes

Alors là je suis prêt à parier que si tu recompiles ton OS avec sizeof(int)=2, tu vas en chier... Unix incite à faire ce genre de suppositions partout.

Sinon, pour revenir aux warnings, y'aurait une solution intermédiaire entre type x=x et warning.
#endif

Genre 
#if defined(__GNUC__) && !defined(JEVEUXDEBUGGERMESWARNINGS)
#define UNINITIALIZED(t,s)	t s = s;
#else
#define UNINITIALIZED(t,s)	t s;

Comme ça ça reste assez voyant sans faire de warning. Et ça reste compilable avec autre chose que gcc.

rogntudju, je ne parle pas de supposer que sizeof(long long)=8, mais je dis juste qu'il n'y a aucun _intérêt_ pour une architecture à avoir sizeof(long long)=16, sauf si le compilateur est mal foutu et ne supporte pas d'avoir un type entier supplémentaire... Mais dans ce cas y a des chances pour que les entiers 128 bits ne soient pas supportés non plus ^^

....
1. Les long long ne sont que rarement supportes nativement par le systeme. C'est en general via une couche d'emulation soft.
2. Les opteron pourraient tres bien avoir sizeof(short)=2, sizeof(int)=4, sizeof(long)=8 et sizeof(long long)=16. Ca simplifierait pas mal de programmes de pouvoir aller jusqu'a 2^80, et plus (qui a dis cassage de cryptosysteme ?). Les long, long seraient efficacement implantes comme les long long le sont sur architecture IA-32.
3. Je ne comprends vraiment pas ce que tu dis.


./73: En C++, le preprocesseur, c'est mal

oula

j'ai toujours appris que short = 2
long = 4 et int = taille d'un pointeur mémoire..

donc int on peut pas s"y fier.. Si on se met a changer la taille des long ça va chier un max de programme

Sur opteron, alpha, sizeof(long)=8...

Si tu veux un type d'entier 32 bits, utilise uint32_t et int32_t.

Godzil :
j'ai toujours appris que short = 2 long = 4 et int = taille d'un pointeur mémoire..

C'est faux. Sur les systèmes LP32 (par exemple TIGCC) ou LP64 (par exemple GCC sur x86-64), ce n'est pas le cas.
Avec les conventions utilisées par GCC (LP32, ILP32 ou LP64), la taille d'un pointeur est long, mais ce n'est pas garanti par le standard non plus. Le C99 prévoit un intptr_t pour ça.
Et long = 4 est aussi faux en LP64.

Voici une manière portable (C90) de trouver les bons types d'entiers pour une taille donnée:

// Attempt to auto-detect I1, I2, I4, SI1, SI2 and SI4 based on <limits.h>.
// It is a good idea to double-check these definitions on every new system
// you compile on.
// Such a check is also performed at run time (or optimized away as dead
// code).

#include <limits.h>

// Make sure that the character types take exactly 1 byte.
#if UCHAR_MAX != 255
#error Need 1-byte unsigned char type.
#endif /* UCHAR_MAX != 255 */
#if SCHAR_MIN != (-128) || SCHAR_MAX != 127
#error Need 1-byte signed char type.
#endif /* UCHAR_MAX != 255 */

// Unsigned types.
typedef unsigned char I1;

#if USHRT_MAX == 65535
typedef unsigned short I2;
#elif UINT_MAX == 65535
typedef unsigned int I2;
#elif ULONG_MAX == 65535
typedef unsigned long I2;
#else /* no 2-byte unsigned int */
#error No 2-byte unsigned integer type found.
#endif /* 2-byte unsigned int */

#if ULONG_MAX == 4294967295
typedef unsigned long I4;
#elif UINT_MAX == 4294967295
typedef unsigned int I4;
#elif ULONG_LONG_MAX == 4294967295 || ULLONG_MAX == 4294967295
typedef unsigned long long I4;
#else /* no 4-byte unsigned int */
#error No 4-byte unsigned integer type found.
#endif /* 4-byte unsigned int */

// Signed types.
typedef signed char SI1;

#if SHRT_MIN == (-32768) && SHRT_MAX == 32767
typedef short SI2;
#elif INT_MIN == (-32768) && INT_MAX == 32767
typedef int SI2;
#elif LONG_MIN == (-32768) && LONG_MAX == 32767
typedef long SI2;
#else /* no 2-byte signed int */
#error No 2-byte signed integer type found.
#endif /* 2-byte signed int */

#if LONG_MIN == (-2147483648) && LONG_MAX == 2147483647
typedef long SI4;
#elif INT_MIN == (-2147483648) && INT_MAX == 2147483647
typedef int SI4;
#elif (LONG_LONG_MIN == (-2147483648) && LONG_LONG_MAX == 2147483647) \
      || (LLONG_MIN == (-2147483648) && LLONG_MAX == 2147483647)
typedef long long SI4;
#else /* no 4-byte signed int */
#error No 4-byte signed integer type found.
#endif /* 4-byte signed int */

(J'ai écrit ça pour le linker de TIGCC.)

Je prefere perso:

#include <stdint.h>

PS: long long est au minimum 64 bits, donc "#elif (LONG_LONG_MIN == (-2147483648) && LONG_LONG_MAX == 2147483647) \" est inutile.

Même chose pour ULONG_MAX==65535, mais je préfère les tenter toutes.

Et le désavantage de <stdint.h> est que c'est un header C99 que pas tous les systèmes n'ont. (Certains ne font même pas confiance à ce que <limits.h> soit là et préfèrent les hacks avec autoconf et sizeof, mais franchement je m'en fiche des systèmes qui prédatent le standard ANSI de 1989.)

Tu as aussi inttypes.h, qui est aussi supporter par pas mal de systemes (et qui definit grosso-modo ce que definit stdint.h).
Donc un petite configure et ca roule.

Et j'avoue que je connais des systemes ou limits.h est buggue

PS: Ils n'utilisent pas des hacks avec sizeof ou autoconf mais plutot:
#define UINT_MAX (~ (unsigned) 0)
#define ULONG_MAX (~ (unsigned long) 0)
#define USHRT_MAX ((unsigned short) ~0)
#define ULONG_HIGHBIT (ULONG_MAX ^ ((unsigned long) ULONG_MAX >> 1))
#define UINT_HIGHBIT (UINT_MAX ^ ((unsigned) UINT_MAX >> 1))
#define USHRT_HIGHBIT ((unsigned short) (USHRT_MAX ^ ((unsigned short) USHRT_MAX >> 1)))
#define LONG_MIN ((long) ULONG_HIGHBIT)
#define LONG_MAX (-(LONG_MIN+1))
#define INT_MIN ((int) UINT_HIGHBIT)
#define INT_MAX (-(INT_MIN+1))
#define SHRT_MIN ((short) USHRT_HIGHBIT)
#define SHRT_MAX ((short) (-(SHRT_MIN+1)))

Ne fonctionne qu'en representation a 2 par contre.

./79: Au passage c'est potentiellement buggue. Je crois que le preprocesseur ne fait ces calculs internes qu'en int (selon la norme c89, mais pas c99), donc il manque des L derriere les const de type long.

PpHd
:

rogntudju, je ne parle pas de supposer que sizeof(long long)=8, mais je dis juste qu'il n'y a aucun _intérêt_ pour une architecture à avoir sizeof(long long)=16, sauf si le compilateur est mal foutu et ne supporte pas d'avoir un type entier supplémentaire... Mais dans ce cas y a des chances pour que les entiers 128 bits ne soient pas supportés non plus ^^

....1. Les long long ne sont que rarement supportes nativement par le systeme. C'est en general via une couche d'emulation soft.

Raison de plus pour les laisser à 64 bits.

2. Les opteron pourraient tres bien avoir sizeof(short)=2, sizeof(int)=4, sizeof(long)=8 et sizeof(long long)=16. Ca simplifierait pas mal de programmes de pouvoir aller jusqu'a 2^80, et plus (qui a dis cassage de cryptosysteme ?). Les long, long seraient efficacement implantes comme les long long le sont sur architecture IA-32.

Mais pourquoi appeler ça "long long" et pas "__int128" ? A moins que la portabilité n'entre pas du tout en ligne de compte, tous les progs actuels utilisant des "long long" vont prendre 2x plus de RAM et être 2x plus lents, sans rien gagner

3. Je ne comprends vraiment pas ce que tu dis.

Moi non plus. Pkoi changer la taille des long long actuels alors qu'il n'y a aucune bonne raison de les faire passer à 128 bits ? A part le cas où les pointeurs passeraient à 128 bits et où on aurait donc besoin d'un size_t de 128 bits et où ce serait donc envisageable que long long soit au moins un size_t (même si c pas obligatoire, hein), ou encore le cas où l'architecture du compilo serait extrêmement rigide et ne supporterait que 5 types entiers différents, je ne vois vraiment pas ce qui pourrait pousser à une telle décision.

./73: En C++, le preprocesseur, c'est mal

./84>
<pub> Le préprocesseur de GTC fait ses calculs avec des longs </pub>

GCC les fait en long long.

Si GTC devait faire ses calculs en long long, il boufferait largement plus de RAM, donc c'est exclus

d'ailleur est-ce utile pour un 68k de faire des caluls en longlong ? je suis pas sur

Y a bien TI-Chess qui utilise des long long pour ses hash (et la seule opération qu'il utilise, c'est le XOR ), mais je suis pas sûr qu'il y en ait des masses d'autres.
bab680dcd4b32a29

Le type de données naturel pour des Sprite64 est long long [64].