Quelques chtittes questions de gros mauvais - Page 2

(attention à la coloration )

Riri (./29) :
Rha j'ai enfin trouvé, mais je pige pas trop pour quoi...


Il faut faire :

*fill = \0;

si qu'elqun peut m'éclairer ça serait gentil, en général j'aime quand m^^eme comprendre ce que je fais.

fill étant un pointeur de char, j'essayais de lui passer un char, mais j'avais un warning, raison pour laquelle j'ai tester sans les quotes, mais bon je comprends toujours pas.

Oops, j'avais pas vu le vrai problème en fait.
'a' => code asci de la lettre a
"a" => string qui contient la lettre a, plus un caractère de fin de chaîne

ici il faut faire *fill = '\0'
il se trouve que '\0' a pour valeur 0 en asci, donc tu peux très bien faire *fill = 0;
(c'est quand même bizarre que "*fill = \0;" compile :s)

attention, ne confonds pas "\0" qui est une chaine de caractères (et donc un tableau de 2 char qui valent tous les deux '\0' ) et '\0' qui est un nombre de type char qui vaut 0
il faut donce écrire *fill = '\0'; ou *fill = 0;
( par contre je sais pas pourquoi *fill = \0; sans quote marche, le compilateur ignore le \ ?)

edit: cross

yeah, même remarque entre parenthèses à la fin du message

Nue (./33) :
il faut donce écrire *fill = '\0'; ou *fill = 0;

Riri (./28) :
*fill = "\0";

Erf c'est bien ce que j'avais commencé par faire, mais ça marchait pas des masses.

Et sinon pour Jyaif, si je veux fermet la chaine, c'est que je récupère ce que rentre l'utilisateur dans un buffer et qu'ensuite je le rend exploitable par les fonctions de traitement des chaines de caractères

Riri (./35) :
Et sinon pour Jyaif, si je veux fermet la chaine, c'est que je récupère ce que rentre l'utilisateur dans un buffer et qu'ensuite je le rend exploitable par les fonctions de traitement des chaines de caractères

Ok, dans ce cas là ya pas le choix ^^

Riri (./28) :
je comprends pas pourquoi la deuxième sollution ne marche pas:
*fill = "\0";

Parce que *fill est un char, et tu tentes de lui affecter un const char *.
Tu devrais écrire *fill = '\0';

Récapitulatif :
"a" est une chaîne de caractères (constante).
'a' est un caractère
"aa" est une chaîne de caractères (constante)
'aa' est invalide.

Merci Sasume , je ne conaissais pas cette subtilité ou tout au moins elle était enfoui bien loin dans ma mémoire, tellement loin que je n'en ai aucune souvenance.

./38 > C'est quand même plus qu'une subtilité, ça fait partie de la syntaxe de base du langage. Mais je t'accorde que cette erreur est courante quand tu passes d'un autre langage au C.

C'est pourtant pas bien compliqué, mais il suffit juste de le savoir.

Rah j'y suis presque, plus qu'un bug à la con qui traine, mais ce soir vu mon état de fatigue, je ne sais pas si je vais le trouver...

Ah merde, j'ai un overflow! Pourquoi la rable de caractère ne vaque jusqu'128 .

Il va falloir que je trouve une astuce

Cool problème résolu, il suffisait d'utiliser des unsigned char.

Sinon j'ai encore un warning qui me soule et que je ne comprend pas:

Voilà le warning :

'buffer' may be used uninitialized in this function

et pourtant voilà ce que je fais avant toute utilisation de buffer :

if(!(buffer = malloc(strlen(message)+1)))
goto fin; //Quitte si on ne peut allouer de mémoire pour le buffer de transcription

Que faut'il faire pour que le compilateur comprenne miex où alors que fais-je mal?

Merci de vos suggestion

on peut avoir le code de la fonction ?

tu peux toujours faire:
unsigned char *buffer = buffer;
ça vire le warning je crois.

./45 > C'est plutôt laid

oui, mais c'est tout ce que je peux dire tant que je connais pas plus son code

Et ça a beau être laid, il y a des situations où c'est indispensable d'utiliser cette astuce.

Attention, c'est une extension GCC, ça.

Bah, pour qu'il n'y ait pas de risque que buffer ne soit pas initialisé, il faut l'initialiser...
unsigned char *buffer = NULL;

Ah oui faut penser à utiliser des constantes à la place des "Nombres magiques". Genre 13 = KEY_ENTER, 264 = KEY_ESC...
Et comme le dit Thepro, toujours intialiser les pointeurs. (Rien de pire que de débugger un programme avec un pointeur invalide).

Bah, les deux ne sont pas indispensables si on sait ce qu'on fait (en revanche, les KEY_ sont une bonne habitude à prendre parce que certains sont des pseudo-constantes, donc il est important de ne pas coder la valeur TI-89 en dur pour la portabilité TI-92+/V200 ou l'inverse).

Je ne suis pas actuellement chez moi, mais je posterai sans doute le code de la fonction.

C'est une fonction qui permet de résoudre facilement plusieurs énigmes de codegame, celles par déplacement de caractère dans l'alphabet.

blackGhost (./12) :
./11 > L'évaluation se fait de gauche à droite. Attention ! Dans le cas d'un ET (&&) , si la première expression est fausse, la deuxième ne sera pas évaluée. Ceci peut conduire à certaines surprises, surtout si l'on fait appel à une fonction dans le test. De même, pour un OU (||), si la première expression est vraie, la deuxième ne sera pas évaluée.

T'es sûr ?

Je crois que dans un programme j'avais une ligne de code
if (CarEntre > 96 && CarEntre < 123 && CarLibre[CarEntre - 97])
où CarEntre devait être une lettre minuscule non accentuée. En mettant une lettre majuscule, CarEntre - 97 donne un nombre négatif, et j'ai eu des erreurs aléatoires dans mon programme à cause de ça.

Si CarEntre est une lettre majuscule, le code qui est dans les accolades du if n'est pas exécuté, je pense que là dessus nous sommes d'accord.
Si on imagine que le test qui est dans les parenthèses du if est évalué en totalité, la lecture de CarLibre[CarEntre - 97] n'a pas de raison de planter le programme. Il ne s'agit que d'une lecture et sur TI il n'y a pas de MMU.

Le bug est certainement ailleurs et donc le plantage n'indique pas que l'expression est évaluée dans sa totalité.

Jonasb, il ne faut pas utiliser de constante littérale comme ça, il faut plutôt écrire :
if (CarEntre >= 'a' && CarEntre <= 'z' && CarLibre[CarEntre - 'a'])

L'opérateur && est évalué en court-circuit, le dernier test n'a même pas lieu pour une majuscule parce que déjà le premier échoue.

Ca a été dit plusieurs fois dans ce topic Kevin hein...