Les membres ayant 30 points peuvent parler sur les canaux annonces, projets et hs du chat.
La shoutbox n'est pas chargée par défaut pour des raisons de performances. Cliquez pour charger.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » FxLibC: La bibliothèque standard C pour les calculatrices
Yatis Hors ligne Membre Points: 579 Défis: 0 Message

FxLibC: La bibliothèque standard C pour les calculatrices

Posté le 22/10/2020 17:39

Salut à toi jeune développeur !
FxLibC est une bibliothèque standard C basé sur l'interface que propose GLIBC, la "vrai" bibliothèque standard.

Alors, je sais, ce n'est pas la première fois qu'une telle initiative est prise mais j'ai de bonnes raisons de le faire :
L'OS de Casio n'est pas adapté pour oser faire un portage de la Glibc original car trop de mécanismes sont manquants et la plupart des abstractions fournies par Casio sont, au mieux, bancales. C'est pourquoi j'ai décidé de refaire une librairie de 0 qui permettra de tirer toute la puissance des OS et permettra d'avoir une interface commune pour les OS Casio monochrome/couleur et des noyaux custom comme Vhex.

Pour l'instant, c'est juste un "proof of concept" où la lib peut être compilée, installée et désinstallée en fonction de l'OS et du format* mais en matière de fonctionnalité, il n'y pas grand-chose d'incroyable, seules quelques fonctions basiques y sont implémenté. Je continuerai de l'améliorer au fur et à mesure de mes expérimentations / projets qui, je l'espère, arriverons bientôt.

Pour pas oublier, voici le lien vers le dépôt Git :
> Lien vers le dépôt Gitea, Vhex-Kernel-Core/fxlibc <


Mes prévisions pour la bibliothèque :
Changement de la gestion des versions
C'est une des choses que je n'ai jamais vraiment regardées mais je vois de plus en plus d'intérêt à avoir une gestion des versions correctes si on veut avoir quelque chose de maintenable dans le temps. Actuellement, la version est obtenable uniquement avec make version et elle est mise a la main dans le makefile. J'avais pensé a une gestion automatique des versions basées sur le git: je cherche le dernier commit avec un tag (tag qui contiendra le major.minor (ex: 2.6)) et le nombre de commit après le tag indique la version des patchs. Mais je ne sais pas s’il y a moyen plus simple et plus "automatisant"(?)

Abstraction de Bfile (l'interface mise en place par Casio pour gérer les fichiers)
Comme je vais devoir implémenter les "appels système" open(), lseek(), close(), etc ; Je me suis dit que j'aurais tout intérêt à faire une vraie abstraction de Bfile car elle apporte trop de contrainte (par exemple, on doit spécifier la taille du fichier qu'on veut créer, il y a quelque subtilité avec l'écriture, c'est lent, ...) Donc j'hésite entre :
1) faire juste des wrappers autour des appels système Bfile: le plus simple mais on aura la plupart des contraintes imposées par le Bfile.
2) faire une plus grosse abstraction sur le Bfile: mais ça implique de "monter" le système de fichier au début du programme, potentiellement plus rapide mais on n'échappera pas aux limitations de création et d'écriture dans un fichier).
3) embarquer un système de fichiers custom en RAM et enregistré les informations uniquement quand l'addins retourne au menu : mais ça pose beaucoup de problèmes organisationnel et architectural car je trouve qu'un FS n'a pas sa place dans une bibliothèque standard. Est-ce qu'il faudrait faire un projet à part ? Si oui alors : comment on relit les deux projets ensemble sans que ce sois infernal pour les développeurs ? Sur quel type de format on part ? Comment l'installer proprement en RAM et où ? Comment et quand installer le FS ? Comment on y accède si le système est isolé de la librairie ?

Personnellement je suis plus pour la 3ᵉ options car elle permettra d'avoir un vrai abstraction sur le FS de Casio et on pourrait implémenter beaucoup plus de fonctions pour la manipulation et la sécurité des fichiers (en plus de gagner en performance(?)) mais ça pose beaucoup de problèmes. À méditer.

Abstraction de la gestion de la mémoire
Est-ce qu'on continue d'utiliser des wrappers autour des appels système pour la gestion de la mémoire (malloc, calloc, free, ...) ? Ou est-ce qu'il faudrait mieux refaire cette partie dans la lib ? Actuellement, j'utilise l'ABI de Casio et Vhex pour la gestion de la mémoire car du côté de Casio c'est flou et du côté de Vhex je n'ai pas le choix car l'entièreté de l'environnement (processus, kernel, FS, ...) est en RAM et je n'ai pas le MMU à disposition. Donc est-ce que ça vaut vraiment le coup d'implementer un tas custom, sachant qu'on aura surement rien de commun entre les différents OS ?

Écriture de la documentation
C'est une des parties cruciales si on veut avoir quelque chose d'utilisable et d'améliorable, seulement je ne sais encore sur quel médium faire la documentation : sur le wiki, faire un topic, générer une documentation HTML / PDF ? D'ailleurs, ça me fait penser, es-ce que la v5 de planet-casio améliore cette partie ? J'entends par là, est-ce qu'il y aura un moyen de synchroniser la bible, le wiki du Gitea et le topic en même temps ? Ça pourrait être extrêmement intéressant de centraliser les projets ainsi que leurs documentations / topics.

Support des librairies dynamique pour Vhex
C'est une des fonctionnalités cruciale pour Vhex car la version 2.0 repose entièrement sur le mécanisme de pouvoir relocaliser / charger des fonctions à la volée. Mais malheureusement, GCC semble ignorer les flags pour la génération des bibliothèques (pourtant on peut créer des exécutables en PIE !). Bref, j'avais envoyé un mail à GCC pour avoir des informations mais je n'ai toujours pas eu de réponse.

Optimisation des fonctions
Hé oui, l'intérêt d'avoir une lib complètement indépendante des OS et communautaire, c'est qu'on va pouvoir optimiser la plupart des fonctions basique ! Attention toute fois, s’il vous prend l'envie de participer, évitez d'écrire du code utilisant des modules hardware pouvant générer des interruptions (comme le DMA et le SPU) a moins d'être absolument certain que le système d'exploitation est capable de les gérer. Mais n'oubliez pas que le but de la lib est d'être la plus indépendante possible vis-a-vis des OS pour faciliter son portage.

Actuellement, rien n'est optimisé et rien n'est garantie de fonctionner comme il est décrit dans la norme POSIX ou dans la documentation de la glibc mais à l'avenir, j'espère pouvoir les respecter le plus fidèlement possible.


D'ailleurs, si vous voulez participer au projet n'hésitez pas ! J'ai besoin de pas mal de retour pour que la bibliothèque puisse être un jour utilisable par d'autre personnes que moi


Précédente 1, 2, 3, 4
Slyvtt Hors ligne Maître du Puzzle Points: 2221 Défis: 16 Message

Citer : Posté le 14/01/2022 20:49 | #


Que dire; whoua !!!
Effectivement c'est un gros gros morceau que tu nous lâches aujourd'hui.
Je suis d'accord avec toi, mis à part scanf et cie, le reste est anecdotique.

C'est sur le canal "Dev", ça passe en "Master" quand ?

Je ferai qq tests et te dirai ce qu'il en est.

+99 pour Lephé
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 14/01/2022 21:17 | #


Merci, en effet c'est un gros morceau ! Pour être honnête j'en ai un peu marre des fichiers maintenant, j'espère que ça tiendra comme ça pendant un petit moment.

C'est sur le canal "Dev", ça passe en "Master" quand ?

De préférence quand ce sera un peu plus testé, même si honnêtement je pourrais le publier n'importe quand.

Note : si tu testes récupère bien gint dev aussi, il y a un fix d'un crash potentiel durant les écritures que je n'ai pas encore intégré à une release.
Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 19/03/2022 21:36 | #


Nouvelle version : fxlibc 1.4.0

Release associée de gint : gint 2.7.1
Release associée du fxSDK : fxSDK 2.7.1

Voici une grosse nouvelle version avec principalement le support des fichiers dans <stdio.h>. (@RDP)

  • <stdio.h>: support du système de fichiers, voir ci-dessous.
  • malloc() indique maintenant errno=ENOMEM si une allocation échoue.
  • Ajout d'une fonction memrchr() dans <string.h> (version naïve).
  • Support pour la compilation en code indépendant de la position (PIC) pour Vhex.
  • Ajout de EINTR et EAGAIN dans <errno.h> : c'est utilisé par la version µSTL de Slyvtt.

Liste des fonctions supportées

Pour rappel, il faut utiliser gint_world_switch() avant de manipuler des fichiers !

  • Les flux standards stdin, stdout et stderr sont supportés, c'est-à-dire qu'on peut maintenant faire printf() dessus. Dans gint, par défaut le texte part dans le vide, mais on peut le récupérer dans une fonction personnalisée.
  • On peut ouvrir des fichiers avec fopen() ou freopen() (mémoire de stockage), ou des descripteurs de fichiers directement avec fdopen() ; cette dernière est très utile pour utiliser les fonctions de <stdio.h> sur des "pseudo-fichiers" (genre le port USB dans le futur). Bien sûr fclose() aussi. On peut ouvrir dans tous les modes, mais le mode texte est identique au mode binaire (ce qui est autorisé par le standard). Le mode "append" (a) ne fonctionne pas tout à fait encore.
  • Contrôle du buffer avec setbuf(), setvbuf() et fflush(). Les buffers permettent de grouper les opérations sur les fichiers, ce qui permet de faire plein de lectures/écritures à la suite en n'accédant réellement au fichier que de temps en temps. Vu le temps que les accès à la mémoire de stockage prennent, c'est assez important ! Le standard autorise uniquement à changer de buffer immédiatement après l'ouverture, mais dans cette implémentation on peut changer de buffer quand on veut.
  • Les fonctions d'I/O de base fread() et fwrite().
  • Les fonctions d'I/O par caractères fgetc(), getc(), getchar(), fputc(), putc(), putchar().
  • Les fonctions d'I/O par chaînes de caractères fgets(), fputs() et puts(), plus l'obsolète et dangereuse gets().
  • La fonction pour "annuler" la lecture d'un caractère, ungetc(). C'est utile dans les lexers. Le standard ne garantit que l'annulation d'un caractère lu, mais cette implémentation garantit autant que la taille du buffer (quand il y en a un). Pour ceux qui n'ont jamais codé une libc sachez que cette fonction à elle toute seule force pas mal de design en amont.
  • Les préférées de toute le monde : printf(), vprintf(), fprintf(), vfprintf(), mais aussi les version pour écrire directement dans un descripteur de fichiers, dprintf() et vdprintf().
  • Les outils de positionnement fgetpos(), fsetpos(), fseek(), rewind() et ftell().
  • La gestion des erreurs avec clearerr(), feof(), ferror() et perror().
  • La fonction de suppression de fichiers ou de dossiers vides, remove().

Fonctionnalités manquantes pour l'instant

  • Il n'y a pas de flux "wide" avec les encodages exotiques. La lib ne les supporte pas du tout actuellement, et c'est pas sur la roadmap.
  • Les permissions ne sont pas suivies par gint encore, donc le mode a ne place le curseur à la fin du fichier qu'après l'ouverture au lieu de le faire avant chaque écriture.
  • Les fonctions rename(), tmpfile() et tmpnam() ne sont pour l'instant pas disponibles. C'est pas une grosse affaire, à part pour rename() pour laquelle on n'a pas d'autre choix que de faire une copie, ce qui est un peu con d'ailleurs.
  • fflush(NULL) n'est pas supporté parce qu'on ne traque pas les fichiers ouverts.
  • Les fichiers ne sont pas automatiquement fermés à la fin de l'add-in, pour la même raison.
  • Les fonctions scanf(), vscanf(), fscanf() et vfscanf() ; l'algorithme de scanf n'est pas encore implémenté.

En gros, il y a quasiment tout... ce qui manque est accessible ; le seul gros morceau c'est scanf().
Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2221 Défis: 16 Message

Citer : Posté le 19/03/2022 21:46 | #


Merci Lephe,
big update. Franchement on a vraiment beaucoup de choses là.
Avec un fscanf, on sera au top
Beau boulot
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 17/05/2022 19:52 | #


Nouvelle version : fxlibc 1.4.1

Release associée de gint : gint 2.8.0
Release associée du fxSDK : fxSDK 2.8.0

Absolument rien de majeur :
  • Correction d'un bug de memset() (oui, encore ! )
  • Ajout de getline() et getdelim() (par Hackcell)
  • Support de l'allocation dynamique dans Vhex (par Yatis)

Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 21/08/2022 22:21 | #


Nouvelle version : fxlibc 1.4.4

Release associée de gint : gint 2.9.0
Release associée du fxSDK : fxSDK 2.9.0

Cette version contient rien de très passionnant, juste quelques bugs et le support nécessaire pour compiler la bibliothèque C++ dans le fxSDK.

  • Support de %lc dans printf() pour afficher des caractères Unicode.
  • Élimination de problèmes récurrents avec <stdint.h> et __restrict__.
  • Ajout de prototypes Unix et de codes d'erreur errno utilisés par la lib C++.

Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2221 Défis: 16 Message

Citer : Posté le 18/03/2023 13:38 | #


Une fois n'est pas coutume, un petit bout de développement de la fxlibc où j'ai pu contribuer durant les dernières semaines.

Je procrastinais depuis longtemps, voulant avoir le support de scanf() et de ses différentes versions dans gint/fxsdk, mais je n'osais pas m'y attaquer. Toucher à fxlibc, c'est plonger dans le terrier du Lapin de Mars d'Alice au Pays des Merveilles.

Bon ceci est maintenant un point révolu puisque un prototype de scanf() (et cie) est en PR dans la branche @dev de fxlibc.

A terme, on aura donc le support de l'intégralité des formats de lecture de scanf() : cf ici pour référence ou ici pour un joli tableau

L'état d'avancement est repris dans le tableau suivant :

// XX = not done yet (but will be done)
// OK = OK, done and tested
// -- = not applicable
// NO = not supported (and will not be done)    only for %lc as long char are not supported by gint

/*************************************************************************************************************/
/*   Specifier   *   Explanation                          * num * hh * h  *none* l  * ll * j  * z  * t  * L  */
/*************************************************************************************************************/
/*       %       *   Parse literal '%'                    * --  * -- * -- * OK * -- * -- * -- * -- * -- * -- */    
/*************************************************************************************************************/
/*       c       *   match a char or several char         * OK  * -- * -- * OK * NO * -- * -- * -- * -- * -- */    
/*************************************************************************************************************/
/*       s       *   match a string                       * OK  * -- * -- * OK * NO * -- * -- * -- * -- * -- */
/*************************************************************************************************************/
/*     [set]     *   match a set of char                  * OK  * -- * -- * OK * -- * -- * -- * -- * -- * -- */
/*************************************************************************************************************/
/*       d       *   match a decimal integer              * OK  * OK * OK * OK * OK * OK * OK * OK * OK * -- */
/*************************************************************************************************************/
/*       i       *   match an integer                     * OK  * OK * OK * OK * OK * OK * OK * OK * OK * -- */
/*************************************************************************************************************/
/*       d       *   match an unsigned decimal integer    * OK  * OK * OK * OK * OK * OK * OK * OK * OK * -- */
/*************************************************************************************************************/
/*       o       *   match a unsigned octal integer       * OK  * OK * OK * OK * OK * OK * OK * OK * OK * -- */
/*************************************************************************************************************/
/*      x,X      *   match a unsigned hexadecimal integer * OK  * OK * OK * OK * OK * OK * OK * OK * OK * -- */
/*************************************************************************************************************/
/*       n       *   return the nb of chars read so far   * --  * -- * -- * OK * -- * -- * -- * -- * -- * -- */
/*************************************************************************************************************/
/*      a,A       *  match a floating point number        * OK  * -- * -- * OK * OK * -- * -- * -- * -- * OK */
/*      e,E       *  match a floating point number        * OK  * -- * -- * OK * OK * -- * -- * -- * -- * OK */
/*      f,F       *  match a floating point number        * OK  * -- * -- * OK * OK * -- * -- * -- * -- * OK */
/*      g,G       *  match a floating point number        * OK  * -- * -- * OK * OK * -- * -- * -- * -- * OK */
/*************************************************************************************************************/
/*       p       *   match a pointer                      * --  * -- * -- * OK * -- * -- * -- * -- * -- * -- */
/*************************************************************************************************************/

// Note : %ms and %m[set] are not implemented (with memory allocation while parsing a chain or a set of characters)


Tout est OK, sauf les '%ls' et '%lc' car les wide chars ('wchar_t') ne sont pas supporté actuellement par gint. Cela pourra faire l'objet d'une extension ultérieure si besoin.

Bien entendu, tout cela a été testé en long en large et en travers avec un addin de test dispo ici (scanftest addin) pour les curieux, et comparé à la glibc 6.2 qui a servi de référence. L'addin 'scanftest' propose 76 tests unitaires sur sscanf() et un cas de lectures multiples depuis un fichier de data via fscanf() avec les assert qui serviront à Lephé pour l'intégration dans fxlibctest.

On pourra avoir des trucs de sauvages comme :

    clear();
    ret = sscanf( "]abcdefghij", "%4[^abdr-v0-9A-F-]%n", str, &n );
    assert( strcmp(str, "]")==0 && n==1 && ret==1 );
    dprint( 1, 130, C_BLACK, "#73 : rd 1[^] : [%s] cn=%d rt=%d", str, n, ret );
    dupdate();
    // #73 : rd 1[^] : []] cn=1 rt=1

    clear();

    ret = sscanf( "]abcdefghij", "%5[^]a-z0-9A-Z-]%n", str, &n );
    assert( strcmp(str, "........................")==0 && n==-20 && ret==0 );
    dprint( 1, 140, C_BLACK, "#74 : rd 1[^] : [%s] cn=%d rt=%d", str, n, ret );
    dupdate();
    // #74 : rd 1[^] : [........................] cn=-20 rt=0

    clear();
    char str3[50] = "................................................";
    ret = sscanf( "Any combi: You can to use any combi.\n", "%*[^:]%*2c%[^\n]%n", str3, &n );
    assert( strcmp(str3, "You can to use any combi.")==0 && n==36 && ret==1 );
    dprint( 1, 150, C_BLACK, "#75 : rd 1[^] : [%s] cn=%d rt=%d", str3, n, ret );
    dupdate();
    // #75 : rd 1[^] : [You can to use any combi.] cn=36 rt=1

    clear();
    char str4[50] = "................................................";
    ret = sscanf( "      This is a line with spaces.\n", " %[^\n]%n", str4, &n );
    assert( strcmp(str4, "This is a line with spaces.")==0 && n==33 && ret==1 );
    dprint( 1, 160, C_BLACK, "#76 : rd 1 [^] : [%s] cn=%d rt=%d", str4, n, ret );
    dupdate();
    // #76 : rd 1[^] : [This is a line with spaces.] cn=33 rt=1


ou la version fscanf() :


    int line=1;
    FILE *fp = fopen("input.txt", "r");

    if (fp == NULL) {
        dprint( 1, line, C_BLACK, "Error: Failed to open file\n");
        line+=10;
        return 1;
    }

    // Test 1: Read an integer
    int i;
    fscanf(fp, "%d", &i);
    dprint( 1, line, C_BLACK, "Test 1: Read integer: %d\n", i);
    line+=10;

    // Test 2: Read a floating-point number
    float f;
    fscanf(fp, "%f", &f);
    dprint( 1, line, C_BLACK, "Test 2: Read floating-point number: %f\n", f);
    line+=10;

    // Test 3: Read a string with spaces
    char s[20];
    fscanf(fp, "%s", s);
    dprint( 1, line, C_BLACK, "Test 3: Read string: %s\n", s);
    line+=10;

    // Test 4: Read a character
    char cc;
    fscanf(fp, "%*c%c", &cc);
    dprint( 1, line, C_BLACK, "Test 4: Read character: %c\n", cc);
    line+=10;

    // Test 5: Read multiple values
    int a, b, d;
    float c1;
    fscanf(fp, "%d%f%d", &a, &c1, &b);
    dprint( 1, line, C_BLACK, "Test 5: Read multiple values: %d, %f, %d\n", a, c1, b);
    line+=10;

    // Test 6: Read a string with spaces using %[^\n]
    char s1[50];
    fscanf(fp, " %[^\n]", s1);
    dprint( 1, line, C_BLACK, "Test 6: Read string with spaces: %s\n", s1);
    line+=10;

avec bien entendu le non oubli du gint_world_switch() qui va bien.

Cela devrait vous être utile pour "égayer" nos addins et importer des fichiers ou gérer des entrées via des fichiers ou des chaines (ou possiblement stdin.

Voila pour ma petite pierre apportée à ce magnifique édifice.

@RDP
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 02/04/2023 00:16 | #


Nouvelle version : fxlibc 1.4.5

Release associée de gint : gint 2.10.0
Release associée du fxSDK : fxSDK 2.10.0

Rien de très gros sur cette version ; le scanf() de SlyVTT arrivera à la suivante.

  • Ajout de fileno(), __cxa_atexit() et atexit()
  • Ajout de l'en-tête <alloca.h>
  • Bugs corrigés : strftime() avait un nom incorrect, srand(1) n'était pas appelé automatiquement au démarrage.

Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 14/01/2024 23:08 | #


Nouvelle version : fxlibc 1.5.0

Cette version ajoute (enfin !) le support de scanf() et associés, grâce à SlyVTT.

  • Ajout de scanf(), vscanf(), sscanf(), vsscanf(), fscanf() et vfscanf()
  • Cela devrait aussi débloquer pas mal d'I/O dans la lib C++ comme std::cin.

L'implémentation n'est pas parfaite et si vous allez chercher des trucs tordus (notamment couper des valeurs au milieu avec la maximum field width) vous risquez de tomber sur des bugs. Mais pour les cas d'usage courants, ça devrait aller tout seul, comme en témoigne la longue liste de tests.
Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Slyvtt Hors ligne Maître du Puzzle Points: 2221 Défis: 16 Message

Citer : Posté le 15/01/2024 08:59 | #


Super, merci beaucoup Lephé, c'est un big morceau en plus pour gint.
Les amis, hésitez pas à tester et à faire vos retours car c'est vraiment le genre de fonctions qui a tellement de possibilités que c'est impossible à tester seul dans son coin (et pour les fichiers, pensez bien au "World Switch" en passant).

Ta TODO list commence à bien réduire, il va falloir qu'on te repasse quelques commandes d'ajouts
Je suis intrigué par HH2. What's this ?
There are only 10 types of people in the world: Those who understand binary, and those who don't ...

Tuper4 Hors ligne Membre Points: 661 Défis: 18 Message

Citer : Posté le 15/01/2024 22:53 | #


Lephenixnoir a écrit :
Nouvelle version : fxlibc 1.4.0

Release associée de gint : gint 2.7.1
Release associée du fxSDK : fxSDK 2.7.1

Voici une grosse nouvelle version avec principalement le support des fichiers dans <stdio.h>. (@RDP)

  • <stdio.h>: support du système de fichiers, voir ci-dessous.
  • malloc() indique maintenant errno=ENOMEM si une allocation échoue.
  • Ajout d'une fonction memrchr() dans <string.h> (version naïve).
  • Support pour la compilation en code indépendant de la position (PIC) pour Vhex.
  • Ajout de EINTR et EAGAIN dans <errno.h> : c'est utilisé par la version µSTL de Slyvtt.

Liste des fonctions supportées

Pour rappel, il faut utiliser gint_world_switch() avant de manipuler des fichiers !

  • Les flux standards stdin, stdout et stderr sont supportés, c'est-à-dire qu'on peut maintenant faire printf() dessus. Dans gint, par défaut le texte part dans le vide, mais on peut le récupérer dans une fonction personnalisée.
  • On peut ouvrir des fichiers avec fopen() ou freopen() (mémoire de stockage), ou des descripteurs de fichiers directement avec fdopen() ; cette dernière est très utile pour utiliser les fonctions de <stdio.h> sur des "pseudo-fichiers" (genre le port USB dans le futur). Bien sûr fclose() aussi. On peut ouvrir dans tous les modes, mais le mode texte est identique au mode binaire (ce qui est autorisé par le standard). Le mode "append" (a) ne fonctionne pas tout à fait encore.
  • Contrôle du buffer avec setbuf(), setvbuf() et fflush(). Les buffers permettent de grouper les opérations sur les fichiers, ce qui permet de faire plein de lectures/écritures à la suite en n'accédant réellement au fichier que de temps en temps. Vu le temps que les accès à la mémoire de stockage prennent, c'est assez important ! Le standard autorise uniquement à changer de buffer immédiatement après l'ouverture, mais dans cette implémentation on peut changer de buffer quand on veut.
  • Les fonctions d'I/O de base fread() et fwrite().
  • Les fonctions d'I/O par caractères fgetc(), getc(), getchar(), fputc(), putc(), putchar().
  • Les fonctions d'I/O par chaînes de caractères fgets(), fputs() et puts(), plus l'obsolète et dangereuse gets().
  • La fonction pour "annuler" la lecture d'un caractère, ungetc(). C'est utile dans les lexers. Le standard ne garantit que l'annulation d'un caractère lu, mais cette implémentation garantit autant que la taille du buffer (quand il y en a un). Pour ceux qui n'ont jamais codé une libc sachez que cette fonction à elle toute seule force pas mal de design en amont.
  • Les préférées de toute le monde : printf(), vprintf(), fprintf(), vfprintf(), mais aussi les version pour écrire directement dans un descripteur de fichiers, dprintf() et vdprintf().
  • Les outils de positionnement fgetpos(), fsetpos(), fseek(), rewind() et ftell().
  • La gestion des erreurs avec clearerr(), feof(), ferror() et perror().
  • La fonction de suppression de fichiers ou de dossiers vides, remove().

Fonctionnalités manquantes pour l'instant

  • Il n'y a pas de flux "wide" avec les encodages exotiques. La lib ne les supporte pas du tout actuellement, et c'est pas sur la roadmap.
  • Les permissions ne sont pas suivies par gint encore, donc le mode a ne place le curseur à la fin du fichier qu'après l'ouverture au lieu de le faire avant chaque écriture.
  • Les fonctions rename(), tmpfile() et tmpnam() ne sont pour l'instant pas disponibles. C'est pas une grosse affaire, à part pour rename() pour laquelle on n'a pas d'autre choix que de faire une copie, ce qui est un peu con d'ailleurs.
  • fflush(NULL) n'est pas supporté parce qu'on ne traque pas les fichiers ouverts.
  • Les fichiers ne sont pas automatiquement fermés à la fin de l'add-in, pour la même raison.
  • Les fonctions scanf(), vscanf(), fscanf() et vfscanf() ; l'algorithme de scanf n'est pas encore implémenté.

En gros, il y a quasiment tout... ce qui manque est accessible ; le seul gros morceau c'est scanf().
Maintenant, il faut le mettre sur Pythonextra . Je rigooole....je ne veux pas t'emcombrer
Vous galérez avec votre menu? Je suis ici pour t'aider!
Tant que c'est C.Basic, python ou C en utilisant gint, ça me va!
Envoyé moi une idée de votre menu en MP et le reste, c'est moi qui gère
Clique sur le lien en dessous pour m'envoyer un MP
https://www.planet-casio.com/Fr/compte/message.php?dest=tuper4
Lephenixnoir Hors ligne Administrateur Points: 24058 Défis: 169 Message

Citer : Posté le 17/01/2024 16:43 | #


C'est drôle mais pas pour tout de suite cependant. Mais c'est noté. :3
Mon graphe (16 Jan): (PythonExtra ; fxsdk#11 ; gint#27 ; (Rogue Life || HH2) ; serial gint ; Boson X ; ...) || (shoutbox v5 ; v5)
Précédente 1, 2, 3, 4

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 32 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd