Ce n'est pas normal de devoir écrire ce genre de casts, c'est plutôt un indice que tu essaies d'écrire du C comme si c'était de l'assembleur.

pareil

ça raye les yeux ce cast


pourquoi pas FilePtr + FileSize - 5?

d'ailleurs ça va foirer pour autre chose que du x86

Le truc, c'est que mon FilePtr est le résultat d'un HeapDeref, donc un void*

Puis je dois calculer l'offset du char FilePtre + FileSize - 5 (merci squalyl, j'y ai pensé j'étais déjà couché ). Je dois donc caster en char*
Puis il me faut un void pour memcmp, donc re-cast en void*.
Ya un autre moyen ?

Il vut pas de l'opérateur & quand j'écris ça :

(void*)&((char*)FilePtr + FileSize - 5)

D'abord je comprends pas pourquoi, et ensuite je vois pas comment faire autrement qu'éviter ces deux casts...

Normalement y'a pas besoin de cast en void*.
Et tu peux pas obtenir un pointeur sur une valeur

Eh merde... je m'en doutais.... alors je fais comment pour récupérer ce p**ain de pointeur en plein milieu de mon tableau ? J'ai essayé de fooler le compilo avec diverses écritures hier soir, sans y arriver :/

Mais le cast en char* reste obligatoire, ça se déréférence par un void* ... Bref, ça reste pas splendide...

(void*)&((char*)FilePtr + FileSize - 5)

non mais non là
qu'est ce qu'il vient foutre au milieu ce &?

FilePtr est déja un pointeur vers ce que tu veux, il pointe juste quelques octets avant, et il a éventuellement pas le bon type. Donc a la limite tu pourrais faire

(void*)((char*)FilePtr + FileSize - 5)

mais vu que void* et char* se comportent de la même manière, tu peux carrément virer tous les casts.

a abuser un compilo, autant le faire proprement

Ah oui n'importe quoi Ca m'apprendra à faire un truc sans réfléchir, putain la honte

Don au final, FilePtr + FileSize - 5 marche très bien. Tout ça pour essayer de faire bien à la base, n'importe quoi

comme un peintre en ascii art, des petits & , * et () un peu partout et hop

N'est-ce pas ? Quel manque de goût ce compilo quand même

http://www.ioccc.org/

bonus:
http://blog.taragana.com/index.php/archive/python-a-recipe-for-cryptic-code/

http://www.de.ioccc.org/years.html#2004_anonymous
Ah oui quand même

je savais que ça te plairait

Tu m'étonnes

Tiens, j'm'a fait baysay :

*((char*)FilePtr + FileSize + 1)

!=

*(char*)FilePtr + FileSize + 1

certes

C'est un peu évident quand même
Faut bien réfléchir à la priorité des opérateurs quand tu codes ^^
Le cast heu déréférencement c'est un "opérateur" avec une des priorités les plus élevées, donc évidemment, ça passe avant le + et beaucoup d'autres

Oui, je m'en suis rendu compte à la relecture, donc j'ai pas galéré dessus. bizarement ça m'a sauté aux yeux, alors que j'y ai même pas pensé quand j'ai écrit...

squalyl (./34) :
vu que void* et char* se comportent de la même manière

Sûr ? #doute#

bah teste mais tu verrais quoi comme différence a part que tu peux pas deref un void*?

ma remarque vaut surtout que x+3 pointe 3 octets après x , que x soit un char* ou un void*.

Justement, je sais que ça semble marcher en pratique, mais je ne sais pas si c'est garanti par le standard C.

Du point de vue logique c'est un peu embêtant : si tu fais pointeur += 3, le pointeur est censé avancer de (3 * taille du type de pointeur) octets. Or void ne représente justement aucun type en particulier...

j'ai vraiment la flemme de ressortir le doc ISO C89 ou 99 (chaipa) mais il me semble qu'il mentionne que sizeof(void) = 1 quand on s'en sert comme pointeur.

en cherchant vite ça semblerait être une extension gcc... merdalors.

bon, m'en fous, j'utilise que gcc , mais c'est bon a savoir.

C'est une extension GCC, en effet.
L'utiliser ou pas est une question de goût - personnellement, je n'aime pas, et c'est une introduction gratuite d'importabilité bien connue entre compilos.