Non, la lib est simplement plus ou moins compressée.
A propos il me semble que j'ai trouvé un bug dans fopen :
if(chmode=='r'|| chmode=='a')
{
flags=_F_READ;
+ sym_entry=DerefSym(SymFind(sptr)); // bugfix
if(!sym_entry)
if(chmode=='r')
{
(et ne rigolez pas, ça m'a déjà planté plusieurs fois ma calc, même si sizeof(FILE) est petit)
> > mais après tout c'est sans doute ce que tu veux.
> Si je suis pour l'ajout de routines à tigcc.a, ce n'est pas pour embêter PpHd et Pollux, mais pour améliorer tigcc.a. Je ne vois pas pourquoi on devrait arrêter de faire évoluer tigcc.a juste parce que ça dérange 2 personnes qui forkent nos routines.
> > Si au moins ca apportait réellement quelquechose mais ca fera la même chose que avant.
> Ça apporte que les fonctions graphiques feront partie intégrante de tigcc.a et qu'il n'y aura plus des copies de extgraph.a qui traînent un peu partout dans les sources.
Perso ça ne me dérange pas, SAUF SI #include <tigcclib.h> suffit pour utiliser les routines d'extgraph. Il faut laisser le #include <extgraph.h>, sinon portage obligatoire pour tous les programmes qui l'utilisent
Et bien sûr, le mieux serait de garder extgraph.a sans le fusionner avec tigcc.a, tout en le distribuant en standard avec TI-GCC...
> Pollux ne veut peut-être pas contribuer ses routines à TIGCCLIB. C'est son choix. Mais c'est un peu dommage... Ca me donne un peu l'impression (peut-être fausse) qu'il ne veut pas faire des choses pour TOUTE la communauté, ce qui est pourtant, de loin, le plus fin...
Je n'ai pas refait de routines de TI-GCC Lib. Et j'ai reporté tous les bugs que j'ai trouvé à la TI-GCC Team...
> De toute facon,si on est un programmeur tres propre,CC de nitro est largement suffisant,sauf qu'il faut trouver des librairies pour le gray et les sprites
très propre
