peek_bit - Page 2

Tu as la taille par taille= *(short *)adresse++ avant d'entrer dans la boucle. En même temps, tu pointeras directement sur le contenu du fichier (sans cette ligne tu commences par lire les bits qui forment la taille).

neria
: Ca marche, c'est génial !!!!

Je n'ai pas choisi mon pseudo par hazard

Pollux :
"--bit" non plus

Ha oué ? revois GTC alors parceque :

neria
: Ca marche, (...) !!!!

Albert Instinct
:

Pollux :
"--bit" non plus

Ha oué ? revois GTC alors parceque :

neria
: Ca marche, (...) !!!!

Je viens de vérifier au cas où avec GCC 3.3.1 :

~ $ cat > thib.c
int x(int y) {return --y&=3;}
~ $ gcc -S thib.c
thib.c: In function `x':
thib.c:2: error: invalid lvalue in assignment

Merci beaucoup !!!

Ca a déjà marché chez moi. Je me souviens que j'avais été surpris. Et ça a l'air de marcher chez neria

Ca a déjà marché chez moi. Je me souviens que j'avais été surpris.

tss tss. Je voudrais bien voir un exemple concret

Et ça a l'air de marcher chez neria

Rien ne te dit qu'il a testé exactement ton code...

Si, j'ai simplement fait copier-->coller en l'adaptant à mes variables. Il apparait une suite de bits, je suppose qu'ils appartiennent à mon fichier, je vérifierais demain car je n'ai vraiment plus le temps !!!

Tu as copié-collé la dernière version? Celle du ./24? Si ça marchait vraiment, ce serait un bug de TIGCC... (en tout cas la version que j'ai le refuse)

Si j'ai copié celle du post 23, ma version de TIGCC est 0.94 SP4

Avec 0.95 b4, ça n'a pas l'air de passer... Probablement un bug de GCC qui a été corrigé depuis.

Albert Instinct :
plus compliquée :char *adresse = HeapDeref(Fichier->handle) ;Si ça ne fonctionne pas, il y a une solution

C'est un hack. Tu n'es pas censé accéder directement aux éléments de la structure FILE. Il y a les fonctions de vat.h pour ça.

Kevin Kofler
:

Albert Instinct :
plus compliquée :char *adresse = HeapDeref(Fichier->handle) ;Si ça ne fonctionne pas, il y a une solution

C'est un hack. Tu n'es pas censé accéder directement aux éléments de la structure FILE. Il y a les fonctions de vat.h pour ça.

ce n'est PAS un hack, puisque le C le permet, et qu'il n'y a AUCUNE utilisation d'assembleur dans la source

Godzil
:

Kevin Kofler
:

Albert Instinct :
plus compliquée :char *adresse = HeapDeref(Fichier->handle) ;Si ça ne fonctionne pas, il y a une solution

C'est un hack. Tu n'es pas censé accéder directement aux éléments de la structure FILE. Il y a les fonctions de vat.h pour ça.

ce n'est PAS un hack, puisque le C le permet

Non. Le contenu de la structure FILE n'est pas défini par le standard C, donc en particulier tu n'as aucun droit de présupposer l'existance d'un membre particulier de la structure. Nous nous réservons le droit de modifier totalement la structure FILE à tout moment.

Pourquoi --var et cousins ne sont plus acceptés ?

Kevin Kofler :
Non. Le contenu de la structure FILE n'est pas défini par le standard C, donc en particulier tu n'as aucun droit de présupposer l'existance d'un membre particulier de la structure. Nous nous réservons le droit de modifier totalement la structure FILE à tout moment.

SAUF, que la il bosse UNIQUEMENT sur TI-68k, ce qui fait que ce genre de comportement n'ammene pas a une imcompatibilité.

Sauf en cas de changement de structure, comme le dit Kevin.
Et puis bon, ce ne sont pas de très bonnes habitudes à prendre, je pense.

Godzil
: SAUF, que la il bosse UNIQUEMENT sur TI-68k, ce qui fait que ce genre de comportement n'ammene pas a une imcompatibilité.

Si dans une version future de TIGCC la structure FILE change (ce qui est tout à fait permis), le programme ne compilera plus.

Ouep, mais bon ... on connait tes programmeurs de tigcc et ils voudonrt jamais apporter une modif qui rendra incompatible avec des version antérieures

bof ...

De toute façon, stdio sur TI...

Ouep, mais bon ... on connait tes programmeurs de tigcc et ils voudonrt jamais apporter une modif qui rendra incompatible avec des version antérieures

hum. qu'est-ce qu'ils ont fait avec le nouveau linker ? enfin, c'est vrai, mes programmes compilent toujours, c'set juste qu'ils sont buggés après

^^ perso j'ai jms eu de gros problèmes avec le nvo linker. (Enfin, p ê qq uns avec Zelda, ms c pas sûr)

il est codé en quoi ? moi à peu près tous mes programmes asm ont eu des problèmes

neria :
Ca marche, c'est génial !!!! Un seul petit problème ( et là je vais passer vraiment pour un con ) Comment obtient-on la taille d'un fichier ?

la ftell peu aider ^^


cherche la doc de fseek, je sus sur que tu va trouver tout seul

Albert Instinct :
Pourquoi --var et cousins ne sont plus acceptés ?

Je n'ai pas compris ta question...

Moi dans PedroM, y'a seulement:
typedef struct __file__s *FILE;

Kevin Kofler
:

Albert Instinct :
Pourquoi --var et cousins ne sont plus acceptés ?

Je n'ai pas compris ta question...

Pourquoi --var provoque une erreur alors qu'avant ça compilait ?

Parce que ce n'est pas du C, tout simplement. Pourquoi ce n'est pas du C? Parce que ça compliquerait la génération de code, la détermination de l-values, etc... (une même valeur serait modifiée et lue deux fois dans une expression, ce qui n'est normalement pas autorisé en C : y-=y+=x n'est pas nécessairement équivalent à y=0) Et en plus, ça serait vraiment pas très utile.

(en fait j'avais cru que tu parlais d'un switch de TIGCC qui s'appelait --var, et je me demandais quel était le rapport avec ce qui précédait )

il parlait de la prédécrémentation, tu as pris le parti de tigcc pour rien.