/* Topic des codeurs couche-tard [2] */

Pylades · Le 12/12/2010, à 18:41

grim7reaper a écrit :

[…]
Sérieusement, c'est quoi cette logique de quitter le programme sur l'absence de '\n' ?
[…]

^D, mon cher, ^D…

Dernière modification par Pylade (Le 12/12/2010, à 18:42)

grim7reaper · Le 12/12/2010, à 18:43

Pylade a écrit :

grim7reaper a écrit :
[…]
Sérieusement, c'est quoi cette logique de quitter le programme sur l'absence de '\n' ?
[…]
^D, mon cher, ^D…

Oui, et ^C et une chaîne trop grande aussi (ce dernier cas est « crade »).
Donc mauvaise condition = do while tout moche.
CQFD

Dernière modification par grim7reaper (Le 12/12/2010, à 18:45)

Pylades · Le 12/12/2010, à 18:45

Je sais ! J'ai déjà dit que c'était crade. Mais je ne vois pas le rapport avec ^C.

grim7reaper · Le 12/12/2010, à 18:48

Pour ton montrer que ta boucle ne gère pas ^D en particulier, mais un peu tout et n'importe quoi (^C, « overflow », …) .

Dernière modification par grim7reaper (Le 12/12/2010, à 18:48)

Pylades · Le 12/12/2010, à 18:56

Pour le cas du tampon trop petit, OK, je sais que c'est crade.
Mais sur un ^C, il se passe le comportement attendu : le programme se chope un SIGINT et s'interrompt.

grim7reaper · Le 12/12/2010, à 18:59

Oui, et je n'ai pas dis le contraire, c'est juste que j'avais l'impression dans ta réponse que tu me disais « ma boucle sert à arrêter le prog sur un ^D et rien que ça ».
Je te montrais juste que non.
Rien de plus.

Sinon se terminer sur un SIGINT n'est pas une fatalité, gdb (entre autre) ne le fait pas.

Dernière modification par grim7reaper (Le 12/12/2010, à 19:00)

Elzen · Le 12/12/2010, à 19:08

La gestion des chaînes de caractères et la lecture des fichiers en C, c'est quand même pas évident, n'empêche…

Genre là, j'ai un char* (variable globale) qui contient le nom d'un programme, et je veux lancer ce programme avec des arguments (la ligne exacte d'arguments est dans un GtkEntry) et récupérer ce qu'il affiche sur la sortie standard, j'dois faire comment ?

Je déclare un second char* que j'aloue à strlen de la commande + strlen des arguments, puis je fais deux strcpy pour mettre la commande et les arguments dedans, puis je le passe à popen, et après je fais un read sur le FILE* renvoyé ?
Comment je sais que j'ai récupéré tout ce que la commande avait à me dire ?

grim7reaper · Le 12/12/2010, à 19:24

ArkSeth a écrit :

La gestion des chaînes de caractères et la lecture des fichiers en C, c'est quand même pas évident, n'empêche…

La lecture de fichier ce n'est pas vraiment plus compliqué que le reste, par contre la gestion des chaînes de caractères oui c'est chiant.

Genre là, j'ai un char* (variable globale) qui contient le nom d'un programme, et je veux lancer ce programme avec des arguments (la ligne exacte d'arguments est dans un GtkEntry) et récupérer ce qu'il affiche sur la sortie standard, j'dois faire comment ?
Je déclare un second char* que j'aloue à strlen de la commande + strlen des arguments, puis je fais deux strcpy pour mettre la commande et les arguments dedans

Non.
Comme tu utilises GTK+ donc GLib il serait plus logique d'utiliser les GString ou au pire les fonctions de manipulation de chaînes.

et après je fais un read sur le FILE* renvoyé ?

fread, fscanf ou fgets plutôt.
Pour le popen, je t'avais déjà conseillé d'utiliser les fonctions de Gtk mais bon tu fais comme tu veux…

Comment je sais que j'ai récupéré tout ce que la commande avait à me dire ?

Comme quand tu lis n'importe quel fichier, EOF (j'ai jamais utilisé popen, mais c'est le comportement que j'en attendrai).

Elzen · Le 12/12/2010, à 19:30

Bah disons que ça me paraît quand même assez bizarre d'utiliser une bibliothèque autre que string.h et std*.h pour faire ça… le fait que ce soit dans une appli GTK ne devrait pas entrer en ligne de compte : si demain, j'veux faire un truc du même genre mais pour une appli en ligne de commande, j'vais pas faire dépendre ça d'une bibliothèque qui n'a absolument rien à voir avec le reste du programme

grim7reaper · Le 12/12/2010, à 19:32

La GLib peut-être utilisé sans Gtk+…
Je pars du principe que quitte a avoir une grosse dépendance, autant qu'elle serve.

ArkSeth a écrit :

si demain, j'veux faire un truc du même genre mais pour une appli en ligne de commande

Si tu as bien séparer le cœur du programme de l'interface ça ne pose pas de problème, seule l'interface est à réecrire.

Dernière modification par grim7reaper (Le 12/12/2010, à 19:37)

Elzen · Le 12/12/2010, à 19:37

Je sais bien, mais tu vas mettre de la GLib dans des petits programmes simples en console, toi ?

J'suis d'accord pour dire que le jour où j'aurai un truc à faire qui dépende vraiment de la GLib ou de GTK, ce sera probablement beaucoup plus pratique avec, mais pour le cas qui m'intéresse ici (concaténer un nom de programme et des arguments, exécuter et lire la sortie), que je suis susceptible d'avoir besoin de reprendre dans n'importe quel programme, je devrais faire ça avec le moins de grosses dépendances possible.

grim7reaper · Le 12/12/2010, à 19:43

ArkSeth a écrit :

Je sais bien, mais tu vas mettre de la GLib dans des petits programmes simples en console, toi ?

Ça dépend de la tâche que devra accomplir le programme.
La GLib simplifie beaucoup de choses (et en rend portable d'autres) donc il n'est pas exclue de l'utiliser pour un programme en console.

J'suis d'accord pour dire que le jour où j'aurai un truc à faire qui dépende vraiment de la GLib ou de GTK, ce sera probablement beaucoup plus pratique avec, mais pour le cas qui m'intéresse ici (concaténer un nom de programme et des arguments, exécuter et lire la sortie), que je suis susceptible d'avoir besoin de reprendre dans n'importe quel programme, je devrais faire ça avec le moins de grosses dépendances possible.

Ce que tu veux faire là n'a rien a voir avec le cœur de ton programme (qui est l'interpréteur) mais dépend de l'interface donc ça ne me choque pas.
Après si tu veux faire ça avec les fonctions de base et bien strlen, strcat & cie sont effectivement tes amis (fait gaffes aux buffer overflow quand même).

Pylades · Le 12/12/2010, à 19:46

~$ cat /usr/lib/python3.1/this.py
s = """Gur Mra bs Clguba, ol Gvz Crgref

Ornhgvshy vf orggre guna htyl.
Rkcyvpvg vf orggre guna vzcyvpvg.
Fvzcyr vf orggre guna pbzcyrk.
Pbzcyrk vf orggre guna pbzcyvpngrq.
Syng vf orggre guna arfgrq.
Fcnefr vf orggre guna qrafr.
Ernqnovyvgl pbhagf.
Fcrpvny pnfrf nera'g fcrpvny rabhtu gb oernx gur ehyrf.
Nygubhtu cenpgvpnyvgl orngf chevgl.
Reebef fubhyq arire cnff fvyragyl.
Hayrff rkcyvpvgyl fvyraprq.
Va gur snpr bs nzovthvgl, ershfr gur grzcgngvba gb thrff.
Gurer fubhyq or bar-- naq cersrenoyl bayl bar --boivbhf jnl gb qb vg.
Nygubhtu gung jnl znl abg or boivbhf ng svefg hayrff lbh'er Qhgpu.
Abj vf orggre guna arire.
Nygubhtu arire vf bsgra orggre guna *evtug* abj.
Vs gur vzcyrzragngvba vf uneq gb rkcynva, vg'f n onq vqrn.
Vs gur vzcyrzragngvba vf rnfl gb rkcynva, vg znl or n tbbq vqrn.
Anzrfcnprf ner bar ubaxvat terng vqrn -- yrg'f qb zber bs gubfr!"""

d = {}
for c in (65, 97):
    for i in range(26):
        d[chr(i+c)] = chr((i+13) % 26 + c)

print("".join([d.get(c, c) for c in s]))

Un module obfusqué ! :]

grim7reaper a écrit :

[…]
Sinon se terminer sur un SIGINT n'est pas une fatalité, gdb (entre autre) ne le fait pas.

Oui, mais je veux m'interrompre sur un SIGINT.

Elzen · Le 12/12/2010, à 20:14

@grim7reaper : disons que je voyais ça du genre avec deux fonctions : une dans la partie cœur qui prenne en paramètre un char* contenant les arguments et qui renvoie le stdout, et une dans la partie gui qui récupère le contenu du GtkEntry, qui appelle la fonction précédente et qui affiche son résultat. Comme ça, le jour où j'aurai besoin de reprendre ça dans un programme plus simple, je n'aurai quasiment qu'à copier-coller la première fonction, indépendamment de la seconde, et j'aurai le truc en parfait état sans avoir besoin de charger la glib. Tu crois vraiment que j'devrais faire autrement ?

(Enfin, dans la pratique, ça va être un peu plus crade que ça : le programme propose deux versions, une en cli et une en gui, et la commande appelée par la fonction ci-dessus sera argv[0]+" <<< "+ducode. Mais bon.)

grim7reaper · Le 12/12/2010, à 20:23

Oui, alors où est le problème d'utiliser les GString ?
C'est dans la partie GUI que tu récupères les infos et que tu les concatènes donc tant que tu passes le char* résultant à la première fonction je ne vois pas où ça coince…

Après, je pense qu'il y a même moyen d'éviter de passer par un process externe mais c'est pas le propos ici (nécessite de modifier un peu l'interpréteur, mais au final ça serait plus « propre »)

Dernière modification par grim7reaper (Le 12/12/2010, à 20:26)

Elzen · Le 12/12/2010, à 20:27

Ça coince dans la mesure où je voulais faire la jonction commande-arguments dans la fonction en question… mais bon, j'peux effectivement faire dans l'autre sens, ce serait peut-être même plus pratique à réutiliser, vu qu'en général, j'ai une commande en un seul morceau à demander…

Et oui, j'suis d'accord avec toi, y a moyen de faire largement plus propre. Mais j'suis un peu feignant, là, et ça me paraissait plus simple de faire comme ça que de me débrouiller pour avoir un FILE* pointant sur une chaîne de caractère interne au programme (vu que c'est ce que mange flex, un FILE*). Ceci dit, si tu vois comment faire, c'est peut-être encore plus simple de faire propre que de faire crade, en fait ?

Dernière modification par ArkSeth (Le 12/12/2010, à 20:29)

Pylades · Le 12/12/2010, à 20:41

Putain !
python-magic ne propose pas de version pour Python 3 sur Maverick !
Mais que fait le Bûcher ?

grim7reaper · Le 12/12/2010, à 20:47

ArkSeth a écrit :

Ça coince dans la mesure où je voulais faire la jonction commande-arguments dans la fonction en question…

Ha bah non, ça c'est crade par contre.

mais bon, j'peux effectivement faire dans l'autre sens, ce serait peut-être même plus pratique à réutiliser, vu qu'en général, j'ai une commande en un seul morceau à demander…

Ouais, là c'est déjà mieux

Ceci dit, si tu vois comment faire, c'est peut-être encore plus simple de faire propre que de faire crade, en fait ?

Ouais, nan je ne sais pas. Il faudrait que je vois le code pour voir quelle modif' faire mais bon c'est pas le but là. C'est plus le côté GTK+ que tu voulais bosser.

Elzen · Le 12/12/2010, à 20:58

Ça dépend : pour mes profs de Compil, c'est le côté yacc+flex, que j'suis censé bosser

Et de toute façon, que je fasse ça avec la glib ou avec les fonctions standard, ça ne me fait pas plus bosser GTK+ dans un cas que dans l'autre (d'autant que j'ai pigé le principe, maintenant, avec la pratique de PyGTK que j'ai déjà, la syntaxe C qui est pas trop mal rentrée, et la doc, j'vois pas grand difficultés pour le reste de la calculatrice. Enfin, j'verrai.)

J'peux peut-être sortir le contenu du GtkEntry (Hum. Un GtkTextView serait plus adapté, en fait, pour pouvoir mettre des retours à la ligne dedans) dans un fichier dans /tmp et ouvrir ledit fichier pour le passer à flex ?

grim7reaper · Le 12/12/2010, à 21:23

ArkSeth a écrit :

Et de toute façon, que je fasse ça avec la glib ou avec les fonctions standard, ça ne me fait pas plus bosser GTK+ dans un cas que dans l'autre

Si car GLib ⊆ GTK+

J'peux peut-être sortir le contenu du GtkEntry (Hum. Un GtkTextView serait plus adapté, en fait, pour pouvoir mettre des retours à la ligne dedans) dans un fichier dans /tmp et ouvrir ledit fichier pour le passer à flex ?

Ouais pourquoi pas.
Il y a des fonctions pour créer des fichiers temporaires proprement (mktemp(), tempnam(), tmpnam(), mkstemp() et tmpfile())

Attention, les 3 premières semblent souffrir de problèmes de sécurité et de fiablilité…

man 3 mktemp a écrit :

Never use mktemp(). Some implementations follow 4.3BSD and replace XXXXXX by the current process ID and a single letter, so that at most 26 different names can be returned. Since on the one hand the names are easy to guess, and on the other hand there is a race between testing whether the name exists and opening the file, every use of mktemp() is a security risk. The race is avoided by mkstemp(3).

C'est probablement le même soucis pous tempnam() et tmpnam().

Dernière modification par grim7reaper (Le 12/12/2010, à 21:34)

Elzen · Le 12/12/2010, à 22:02

Visiblement, j'ai pas encore autant progressé que ce que je croyais

Voilà ma fonction dans son ensemble. À la compilation, ça me sort un warning parce que result n'est pas initialisé, et le GtkDialog m'affiche un caractère indéterminé, probablement à cause de ça.

(win et screen sont des variables globales)

void show_result(GtkWidget *widget, gpointer data) {
    GtkTextIter start, end;
    GtkTextBuffer* buffer;
    GtkWidget* dialog;
    char* result;
    char* text;
    
    buffer = gtk_text_view_get_buffer(screen);
    gtk_text_buffer_get_start_iter(buffer, &start);
    gtk_text_buffer_get_end_iter(buffer, &end);
    text = (char*) gtk_text_buffer_get_text(buffer, &start, &end, 1);
    
    yyout = tmpfile();
    yyin = tmpfile();
    
    fprintf(yyin, "%s", text);
    yyparse();
    fscanf(yyout, "%s", result);
    
    dialog = gtk_message_dialog_new(win,
        GTK_DIALOG_DESTROY_WITH_PARENT,
        GTK_MESSAGE_OTHER, GTK_BUTTONS_NONE,
        "%s", result
    );
    gtk_window_set_title((GtkWindow*) dialog, "Résultat");
    gtk_window_set_icon((GtkWindow*) dialog, gtk_icon_theme_load_icon(
        gtk_icon_theme_get_default(), "gcalctool",
        48, GTK_ICON_LOOKUP_USE_BUILTIN, NULL
    ));
    gtk_dialog_run((GtkDialog*) dialog);
}

Deux questions, donc : comment j'initialise result, et est-ce que le reste du code vous semble correct ?

Dernière modification par ArkSeth (Le 12/12/2010, à 22:04)

grim7reaper · Le 12/12/2010, à 22:10

ArkSeth a écrit :

comment j'initialise result

result = NULL;

par exemple ou alors en allouant de la mémoire pour lui (voir ce qui suit)

et est-ce que le reste du code vous semble correct ?

Non,

fscanf(yyout, "%s", result);

ça va chier, tu n'as pas alloué de mémoire pour result donc ça va très mal se passer…

Et puis, il faudra libérer la mémoire de text (avec g_free() je pense) et de result (avec free()).

Dernière modification par grim7reaper (Le 12/12/2010, à 22:13)

Elzen · Le 12/12/2010, à 22:13

Oui, j'me doutais qu'il y aurait un problème de ce côté-là (d'où le fait que je n'ai pas retenu result = NULL comme solution valide, vu qu'utiliser NULL comme adresse de destination de la chaîne lue, ça le fait moyen).
Mais comment j'peux savoir de quelle taille j'vais avoir besoin ?

(La manipulation de fichiers, j'ai toujours eu du mal, quel que soit le langage Enfin, en PHP, j'y arrive plutôt bien, maintenant, donc je suppose que j'peux progresser en C aussi ^^)

grim7reaper a écrit :

Et puis, il faudra libérer la mémoire de text (avec g_free() je pense) et de result (avec free()).

Ah oui, tiens, j'me disais bien que j'avais oublié un truc.

Dernière modification par ArkSeth (Le 12/12/2010, à 22:14)

compte supprimé · Le 12/12/2010, à 22:16

Bn;

grim7reaper · Le 12/12/2010, à 22:16

ArkSeth a écrit :

Mais comment j'peux savoir de quelle taille j'vais avoir besoin ?

C'est là que ça devient drôle, tu ne peux pas à tout les coups.
Bon là on est dans un cas simple donc je pense qu'il te suffit de récupérer la taille du fichier et d'allouer un buffer de la bonne taille.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#2276 Le 12/12/2010, à 18:41

Re : /* Topic des codeurs couche-tard [2] */

#2277 Le 12/12/2010, à 18:43

Re : /* Topic des codeurs couche-tard [2] */

#2278 Le 12/12/2010, à 18:45

Re : /* Topic des codeurs couche-tard [2] */

#2279 Le 12/12/2010, à 18:48

Re : /* Topic des codeurs couche-tard [2] */

#2280 Le 12/12/2010, à 18:56

Re : /* Topic des codeurs couche-tard [2] */

#2281 Le 12/12/2010, à 18:59

Re : /* Topic des codeurs couche-tard [2] */

#2282 Le 12/12/2010, à 19:08

Re : /* Topic des codeurs couche-tard [2] */

#2283 Le 12/12/2010, à 19:24

Re : /* Topic des codeurs couche-tard [2] */

#2284 Le 12/12/2010, à 19:30

Re : /* Topic des codeurs couche-tard [2] */

#2285 Le 12/12/2010, à 19:32

Re : /* Topic des codeurs couche-tard [2] */

#2286 Le 12/12/2010, à 19:37

Re : /* Topic des codeurs couche-tard [2] */

#2287 Le 12/12/2010, à 19:43

Re : /* Topic des codeurs couche-tard [2] */

#2288 Le 12/12/2010, à 19:46

Re : /* Topic des codeurs couche-tard [2] */

#2289 Le 12/12/2010, à 20:14

Re : /* Topic des codeurs couche-tard [2] */

#2290 Le 12/12/2010, à 20:23

Re : /* Topic des codeurs couche-tard [2] */

#2291 Le 12/12/2010, à 20:27

Re : /* Topic des codeurs couche-tard [2] */

#2292 Le 12/12/2010, à 20:41

Re : /* Topic des codeurs couche-tard [2] */

#2293 Le 12/12/2010, à 20:47

Re : /* Topic des codeurs couche-tard [2] */

#2294 Le 12/12/2010, à 20:58

Re : /* Topic des codeurs couche-tard [2] */

#2295 Le 12/12/2010, à 21:23

Re : /* Topic des codeurs couche-tard [2] */

#2296 Le 12/12/2010, à 22:02

Re : /* Topic des codeurs couche-tard [2] */

#2297 Le 12/12/2010, à 22:10

Re : /* Topic des codeurs couche-tard [2] */

#2298 Le 12/12/2010, à 22:13

Re : /* Topic des codeurs couche-tard [2] */

#2299 Le 12/12/2010, à 22:16

Re : /* Topic des codeurs couche-tard [2] */

#2300 Le 12/12/2010, à 22:16

Re : /* Topic des codeurs couche-tard [2] */

Pied de page des forums