Forum TI-Planet.org

parisse a écrit:

Code: Tout sélectionner

...
#if 1 // def GIAC
  char buf[1024]="regroup(";
  strcpy(&buf[8],c);
  buf[strlen(buf)]=')';
  buf[strlen(buf)]=0;
  const char * out=caseval(buf);
  strcpy(m_inputText,c);
  strcpy(m_exactOutputText,out);
  strcpy(buf,"evalf(");
  strcpy(&buf[6],out);
  buf[strlen(out)+6]=')';
  buf[strlen(out)+7]=0;
  out=caseval(buf);
  strcpy(m_approximateOutputText,out);
#else
...


Rien à avoir avec le problème de faire accepter les commandes xcas, mais on peut améliorer la lisibilité et maintenabilité (pas besoin de calculer et indiquer des offsets) en mettant ceci :

Code: Tout sélectionner

...
#if 1 // def GIAC
  char buf[1024];
  sprintf(buf, "regroup(%s)", c);
  const char * out = caseval(buf);
  strcpy(m_inputText, c);
  strcpy(m_exactOutputText, out);
  sprintf(buf, "evalf(%s)", out);
  out = caseval(buf);
  strcpy(m_approximateOutputText, out);
#else
...


J'ai l'habitude de travailler avec des libc partielles en embarque, strcpy est toujours present (parce que facile a coder), alors que la presence de sprintf est aleatoire (ou/et partielle, bugguee, etc.)

Je n'ai rien contre ça, et d'ailleurs on voit en effet des comportements partiels/pas-terrible de la famille (s)printf sur CE par exemple, m'enfin sur NumWorks il ne devrait pas y avoir de problème

Je ne sais pas en fait, si j'ai bien compris ils ont aussi leur propre lib pour remplacer la libc. Alors plutot que de devoir faire face a un probleme dans la version hardware plus tard, je prefere n'utiliser que strcpy.
Je vais mettre un point d'info sur l'etat de l'avancement du portage sur le fil de la N110 (peut-etre qu'il faudrait creer un fil a part dans les news Numworks?).

parisse a écrit:Je ne sais pas en fait, si j'ai bien compris ils ont aussi leur propre lib pour remplacer la libc. Alors plutot que de devoir faire face a un probleme dans la version hardware plus tard, je prefere n'utiliser que strcpy.

NumWorks utilise effectivement leur propre libc pour la calculette (https://github.com/numworks/epsilon/tree/master/liba). Elle est extrêmement spartiate et ne contient que le strict nécessaire pour exécuter le firmware officiel. Entre autres, il n'y a pas de strcpy car ils n'utilisent que strlcpy.

Mouarf, j'avais oublié ce "détail", même si j'avais été au courant.

OK, il faudra que je modifie, de toutes facons il fallait que je modifie pour controler le non depassement de taille.

J'ignore depuis quand, mais il semble que NumWorks distribue depuis un moment une version 11.2.0 différente.

Celle datant de cette annonce a pour identifiant 454682b et fait effectivement 820,272Ko :
archives_voir.php?id=2225066

La nouvelle a pour identifiant 07a9e90 et ne fait plus que 736,992Ko :
archives_voir.php?id=2329120

Activation d'optimisations ?

Voici entre autres pourquoi le calcul littéral a été supprimé, à cause du Royaume-Uni :
https://github.com/numworks/epsilon/issues/949

Une issue demande son retour, avec par exemple une option d'activation liée ou pas au mode examen :
https://github.com/numworks/epsilon/issues/1099