Bonjour,
J'aimerais protéger mon programme des overflow, notamment lors de la saisie de chaîne par l'utilisateur.
J'ai donc, coder ma petite fonction de saisie utilisant fgets.
fgets(str, sizeof str, stdin);
Erreur de compilation , une petite recherche m'a permis de me rendre compte que stdin sur une TI, ca n'existe pas.

Y-a-t-il moyen d'utiliser fgets, ou alors existe-t-il une autre méthode pour protéger des overflow ?

Merci d'avance

http://tigcc.ticalc.org/doc/stdio.html#getsn

Merci, exactement ce qu'il me fallait.

Je sais pas ce qui ne vas pas, mais getsn ne fonctionne pas.
Si je saisie une chaîne, et que je valide par enter, ca ne met pas fin à la saisie, ca saute simplement une ligne.

Sinon j'ai trouvé une autre méthode dans la FAQ avec ngetchx().

Tu utilises quoi comme compilateur? Et quelle version?

J'utilise l'IDE tigcc v 0.95 avec VTI.

J'ai trouvé, enfaite c'est pas getsn qui allait pas, c'est ce qui suivait, je vidais le flux stdin avec getchar

Le seul problème est qu'avec getsn, je peux saisir max 3 caractère (malgré la taille de size qui est à 16).
Je saisie 3 caractères, puis j'ai beau appuyer sur une touche, rien ne s'ajoute après ces 3 caractères. Je peux juste faire enter pour valider ma saisie.

La 0.95 est obsolète, essaie la 0.96 Beta 8.

Bien que l'upgrade depuis TIGCC 0.95 vers TIGCC 0.96 Beta 8 (ou plus récent) soit plutôt une bonne idée, il n'est pas garanti que cela change le comportement de son programme: ni getsn.s, ni fputchar.s, ni fgetchar.s, ni fgetchrc.s n'ont été modifiés depuis que le repository CVS de TIGCC existe (c'est à dire, depuis une date légèrement postérieure à TIGCC 0.95, mais antérieure à TIGCC 0.96 Beta 1).

J'ai peut-être une solution qui pourrait te convenir
Récupère ce truc : http://ti-fr.com/?co=1&n=264
Prends les fichiers likeonpc.h et errno.h, et copie-les dans C:/Program Files/TIGCC/Include/C.
En faisant #include <likeonpc.h> Tu auras un getsn avec curseur comme sur PC, qui à priori fonctionne très bien. Note importante : la fonction principale de ton programme devra s'appeler main et non plus_main.
Si tu optes pour GTC, tu peux copier tous les fichiers et faire une inclusion plus standard qui sera #include <stdio.h>

Je déconseille fortement l'utilisation de ces hacks qui grossiront ton programme, il vaut mieux apprendre la programmation sur TI directement. Et puis, Thibaut, je ne comprends pas l'intérêt de ton histoire de curseur dans getsn.

S'il y a un problème avec notre fonction getsn, il faudra la corriger, pas la remplacer avec une autre implémentation qui pourrait avoir d'autres bogues.

L'exemple

char buffer[50]; 
int a, b; 
clrscr (); 
puts ("A = "); 
a = atoi (getsn (buffer, 50)); 
puts ("B = "); 
b = atoi (getsn (buffer, 50)); 
printf ("%d + %d = %d", a, b, a+b);

donné dans la doc de getsn fonctionne pour moi (GCC4TI SVN HEAD).
Shadow_C, poste-nous STP ton code

Un truc qui me vient: essaierais-tu d'utiliser sizeof sur un tableau alloué dynamiquement? Ce n'est pas possible, ça donnera toujours la taille d'un pointeur (4 octets), donc forcément il n'acceptera que 3 caractères (4 - 1 pour le '\0'). Passe directement la taille que tu as allouée, pas sizeof(ptr).

Kevin Kofler (./10) :
Je déconseille fortement l'utilisation de ces hacks qui grossiront ton programme

Aucun hack, simplement une réimplémentation. Quant à la grosseur, il peut rien en avoir à faire, d'autant plus que le gets de TIGCC est tellement pourri que tout programme demandant une saisie à l'utilisateur embarque sa propre redéfinition.

Kevin Kofler (./10) :
je ne comprends pas l'intérêt de ton histoire de curseur dans getsn.

Regarde plus attentivement le gif animé, tu devrais comprendre facilement.

Ta bidouille de _main est un hack, faire ça proprement demande beaucoup plus de travail, probablement aussi au niveau du linker.

A toi de jouer !

Kevin Kofler (./14) :
Ta bidouille de _main est un hack, faire ça proprement demande beaucoup plus de travail, probablement aussi au niveau du linker.

Comme beaucoup de ce qui est comme de démarrage dans TIGCCLIB, t'es drôle à lire

Justement, ce code de démarrage est l'exemple de comment faire les choses proprement.

Un truc qui me vient: essaierais-tu d'utiliser sizeof sur un tableau alloué dynamiquement? Ce n'est pas possible, ça donnera toujours la taille d'un pointeur (4 octets), donc forcément il n'acceptera que 3 caractères (4 - 1 pour le '\0'). Passe directement la taille que tu as allouée, pas sizeof(ptr).

Oui c'était ca, en effet, j'ai vite affiché le sizeof de mon "tableau" et j'ai remarqué mon erreur.

J'ai finalement opté pour faire moi même ma fonction en m'inspirant du modèle donné dans la FAQ, ca me permet de filtrer les caractères que l'utilisateur entre.

Qu'est-ce qu'il faudrait changer pour que le _main de likeonpc soit propre selon tes critères (en supposant que tes critères soient bons) ? Tu parles beaucoup mais n'apportes rien, comme toujours.

Bah, faudrait que je me plonge dessus et commence à coder, c'est comme ça que je vois comment faire les choses au mieux, c'est dur de le dire comme ça au préalable.

OK, tu ne sais même pas ce qui pourrait te déplaire. On va finir par croire que tu critiques le travail des gens juste pour le plaisir de te croire meilleur.

Il faut un certain feeling pour coder quelque chose de bien pensé, et c'est souvent en essayant qu'on y arrive. Tout ce que je peux dire, c'est que ta solution ne me convient pas. Le problème principal est que certaines propriétés du wrapper devraient être configurables, par exemple la manière de gérer les codes d'erreurs retournés par main (et exit devrait adopter le même comportement pour être cohérent), ou encore le clrscr implicit. De plus, rajouter des fonctionnalités d'édition à stdio.h et avoir un main ISO sont 2 choses totalement différentes qui ne devraient pas dépendre l'une de l'autre. L'utilisation de tableaux de taille fixe est aussi un signe de mauvaise conception.

C'est un problème assez compliqué. S'il y avait une solution simple, elle serait déjà implémentée!

T'as toujours la même difficulté à discerner les principes généraux des cas particuliers. Va taper plus de 256 caractères dans les arguments... Ça passe sur PC ça d'ailleurs ? Si on augmente la taille maximale des arguments à 4000 octets, tu trouveras encore que ce ce sera trop peu ? Y'a un moment où il faut arrêter d'être ridicule. Une taille dynamique creuserait des trous dans le tas. J'appelle pas ça une solution convenable. Et toi ?

L'utilisation des nouvelles fonctions I/O n'a jamais été dépendante du _main. Tu parles sans savoir.

A moins que tu ne lock pas ton handle contenant les arguments ? Ca permet de garder un heap fluide. Je dis ça, ce n'est qu'une idée, je ne sais pas comment ça serait appliquable à ton soft.

Le comportement correct, c'est de ne permettre que des chaînes de caractères comme arguments et de mettre directement des pointeurs sur la pile d'expressions (cf. GetStrnArg) dans argv. La recopie ne sert à rien.

Ton argumentation, ça me rappelle "640 KB should be enough for everyone".

256 caractères d'arguments sont vite atteints, surtout pour un portage d'un programme PC.

Sans vouloir foutre la merde (mais bon, vu que le topic est déjà en HS complet j'ai pas trop de remords ) c'est vrai qu'un tableau de taille statique pour contenir les arguments (que ce soit 256 ou 4000 octets) c'est tout pourri

(et bien sûr que ça passe avec beaucoup plus d'argument, heureusement d'ailleurs, sinon les commandes genre "grep blabla `find . -name '*.log'`" ça serait pas joyeux )

Eh bien moi, Kevin, je touve que ta solution est naze Passer plusieurs arguments ou même passer un switch suivi d'une valeur nécessiterait de tout mettre dans des guillemets séparés par des virgules. Et que dire des appels de fonctions/programmes qui retournent des valeurs numériques, puisque tu parles de ça Zephyr ? Il faudrait les appeler au préalable et recopier les résultats à la main.
Une solution si bordélique ne mérite même pas d'être étudiée face à la solution actuelle.

Je viens de redécouvrir les possibilités assez spéciales que le TIOS offre sur les blocs de mémoire. On peut allouer un bloc flottant, le réallouer, etc, et finir par le monter tout en haut du tas en le bloquant. On est certain que cette séquence d'opérations ne laissera pas de trou dans le tas ?

Si oui, on peut faire comme ça :
- commencer à écrire argv sur le bloc alloué dans la pile
- en cas de dépassement, allocation d'un bloc pour poursuivre l'écriture (et réallocations au besoin).
- bloquage du bloc en tête de tas.

Il ne faudrait pas que le code qui fait tout ça dépasse 256 octets, sinon le gain de RAM obtenu grâce à l'allocation sur la pile serait perdu.

Moi, je trouve que ton bidouillage est naze. En plus, si tu parses les espaces dans les chaînes, que faire si tu veux passer un argument qui contient un espace? Un bordel de quotes par dessus celui déjà nécessaire pour les chaînes TIOS?

Pour convertir un nombre en chaîne de caractères, le TI-BASIC propose la gentille fonction string.

Et si on veut vraiment gérer les arguments de tout type, on n'a qu'à utiliser les fonctions natives directement, pas le layer de compatibilité C ISO.