tableaux - Page 3

" ça va pointer à douzes octets plus loin que la donnée non?"
Non, ça dépend de sizeof(pointé); ça pointera à 12*sizeof(pointé).

Martial Demolins
: ça va pointer à douzes octets plus loin que la donnée non? du coup, c'est jamais qu'un offset. Ca devrait avoir un sens si 'pointé' était un handle contenant divers types de données.

Heu ça a un sens, ça a toutes les chances de faire planter si on affecte une valeur après mais ça reste valide, c'est ce que je voulais dire ^^

Non, c'est pas valide... En pratique je crois pas que sur TI il y ait des compilateurs que ça gêne, mais en principe tu n'as pas le droit ne serait-ce que de calculer un pointeur qui pointe en dehors d'un tableau (seule "exception" : tu peux pointer juste après le dernier élément d'un tableau, même si tu ne peux évidemment pas le déréférencer)

Oui enfin dans l'exemple dont on parle "pointé" était un short déclaré tout seul, donc ça n'a pas de sens de faire "&pointé+12", il n'y a que "&pointé+1" qui pourrait être valide...

ça dépend : Dans une fonction à pas mal de paramètres, &pointé+12 peut correspondre à l'un d'eux... (enfin, si on ne sauve pas tous les registres.)
Les fonctions comme printf() doivent également utiliser des pointeurs pour accéder aux paramètres supplémentaires (même si elles passent rarement par les variables locales)

Link
: ça dépend : Dans une fonction à pas mal de paramètres, &pointé+12 peut correspondre à l'un d'eux...

Quand on dit qu'un code est "valide" au sens du standard C, ça ne veut pas dire qu'il peut marcher avec de la chance, ça veut dire qu'il marche tout le temps...

(et même en pratique sur les compilos TI c'est faux, à cause du passage par registre)

Les fonctions comme printf() doivent également utiliser des pointeurs pour accéder aux paramètres supplémentaires (même si elles passent rarement par les variables locales)

Ca c'est autre chose, c'est <vararg.h> et là pour le coup c'est garanti par le standard C (et on n'y accède pas par des pointeurs, mais par des macros spéciales). Mais ça n'a rien à voir avec un "short" que tu aurais déclaré tout seul comme variable locale ou comme paramètre "non supplémentaire"...

Pollux
: Non, c'est pas valide... En pratique je crois pas que sur TI il y ait des compilateurs que ça gêne, mais en principe tu n'as pas le droit ne serait-ce que de calculer un pointeur qui pointe en dehors d'un tableau (seule "exception" : tu peux pointer juste après le dernier élément d'un tableau, même si tu ne peux évidemment pas le déréférencer)

http://databob.free.fr/Volume/files/c_valide.png
Cool, ma version de GCC vaut cher alors, elle doit être rare ?
(plus serieusement je ne vois pas ce qu'on peut reprocher à la syntaxe)

Vertyos :
http://databob.free.fr/Volume/files/c_valide.png
Cool, ma version de GCC vaut cher alors, elle doit être rare ?

Si elle est capable de déterminer statiquement si un programme est conforme au standard C ouais elle doit être vachement rare

(plus serieusement je ne vois pas ce qu'on peut reprocher à la syntaxe)

La syntaxe, on ne lui reproche absolument rien, mais la sémantique, on lui reproche quelque chose

Pollux :
Si elle est capable de déterminer statiquement si un programme est conforme au standard C ouais elle doit être vachement rare

Bah depuis qu'il a posté ça je réponds que par rapport à la nature des operateurs (puisque c'est de ça qu'il parlait avant, savoir comment marchent les pointeurs, etc...), c'est tout à fait correct. Après, si ça risque de planter le prog ou pas, oui surement mais c'est pas le sujet là

ok, mais la "nature des opérateurs" et "comment marchent les pointeurs" ça relève au moins autant de la sémantique que de la syntaxe, non ? (enfin je vois bien ce que tu veux dire, mais le fait de dire que c'est effectivement invalide n'est pas du tout hors sujet)

Tu sais je ne connais même pas la définition de "sémantique" alors... (remarque du coup j'en parlais peut-être, hein mais c'était probablement pas le but, je viens d'expliquer les limites de ce que j'appelle "valide" dans ce cas, et ça s'arrête là)

"syntaxe" = "description de la forme"
"sémantique" = "description du sens"

Et c'est pas parce qu'un programme compile sans warnings mais segfaulte qu'il est valide (ni même parce qu'il marche avec des données précises ou une version d'un compilateur précis), stou.

Ça dépend ce que tu considères comme étant "valide", encore une fois. Par rapport au contexte, j'ai expliqué en quoi ça l'était pour moi (comme d'hab j'ai l'impression de me répeter et de tourner en rond pr quelque chose sans interet...)

tourner en rond, je sais pas, mais sans intérêt, sûrement ^^

Toujours et seulement avec toi curieusement, peut-être que c'est un [jeu] que j'ai loupé, de chercher tjrs à contredire n'importe quoi n'importe comment pr le plaisir... Enfin bref, retour au topic.

Vertyos :
e chercher tjrs à contredire n'importe quoi n'importe comment pr le plaisir...

tien moi aussi!!

pour resoudre mon probleme je vais retourner les valeur dans un tableau (y'a deux valeurs)
declaration

short fonction(short a)
{
  short ia[2]
  ia[0]=2*a
  ia[1]=3*a
  return ia
}

appel

short coordia[2]
coordia=fonction(2)

ça ne marche pas, ça.
en plus, tu retournes un pointeur vers une variable locale, qui est déja détruite quand la fonction retourne, et qui sera modifiée au prochain appel de fonction...

Tu dois passer l'adresse du tableau à ta fonction :

void fonction(short a, short ia[2])
{
ia[0] = 2*a;
ia[1] = 3*a;
}

short coordia[2];
fonction(2, coordia); //En passant un tableau, on passe son adresse

En plus ce que tu appelles déclaration est une définition.

les ppg c'est encore utilsé?
au depart c'est pour contourner les protection sur la taillle des programme limité a 8Ko
maintenant qu'elle est a 64ko y'en a plus besoin

C'est surtout pour la compression.

pour etre compatible
c'etait pas une sources de problemes sur 89 titanium?

Pour qu'un même programme marche sous les différents AMS.

> les ppg c'est encore utilsé?
Par presque tous les programmes qui dépassent une certaine taille (~12 KB).
A peu près aucune autre compression à sens unique n'est utilisée sur les TI-68k pour les programmes, c'est aussi simple que ça...
> c'etait pas une sources de problemes sur 89 titanium?
Réponse courte: non.
Réponse longue: les problèmes étaient dans le lanceur de PPG (méthode de lancement qui ne marche pas sur la Titanium) et dans les programmes compressés en PPG (code non compatible Titanium). Le format lui-même n'a aucune incidence là-dessus.

Sujet glissant, puisque touchant aux kernels...
En nombre de programmes compressés dans chacun des deux formats, il n'y a pourtant pas photo... Une pondération par le nombre de calculettes qui les utilisent rééquilibre un peu, car chaque kernel avec "stdlib" contient de nombreuses librairies, même si les kernels ne sont pas sur la majorité des calculatrices, et que pas tous les utilisateurs de kernels n'utilisent stdlib.