pb ac malloc - Page 1

j'utilise malloc comme ceci:
char *lang=malloc(3);
*lang="en";

et ca fait planter la TI je c pa pqoi

memcpy()

char *lang=malloc(3);
memcpy(lang,"en",3);
??

strcpy() est mieux d'ailleurs, lis la doc

limmt> C'est vraiment la base du C ça ! Apprends le C avant d'essayer de programmer en C (ce n'est pas la première fois qu'on te le dit).
Sinon, tu peux faire ça :
char *str;
str=(char *)"chaine";

Mais c'est trompeur.

Sasume a raison. Apprends à programmer en C.

kler, parce qu'assigner à un pointeur une chaîne, faut le faire

ouais... sinon strcpy peut suffire pour des chaines immédiates, mais sinon le strncpy vaut parfois mieux pour éviter les plantages...

je ne suis aps d'accord, strncpy prend plus de place que strcpy dans un prgm et strcpy copie jusque rencontre du caractere '\0' donc ca ne doit a priori pas planter si on fait pas n'importe quoi

Voilà, après tout dépend de l'utilisation qu'on veut en faire. Si un petit programme plante quand on lui donne un nom de fichier de 200 caractères, ben c pas la mort parce qu'il fallait juste pas jouer au con. Après, si on programme sur PC et qu'on veut faire un truc secure, faut commencer à faire gaffe, mais sur TI c pas super grave. Et on peut toujours rajouter des vérifications avec strlen...

liquid
: je ne suis aps d'accord, strncpy prend plus de place que strcpy dans un prgm et strcpy copie jusque rencontre du caractere '\0' donc ca ne doit a priori pas planter si on fait pas n'importe quoi

N'importe quoi. Utiliser strcpy sur une chaîne dont la longueur n'est pas connue à l'avance (ou plutôt dont aucune borne supérieure raisonnable pour la longueur n'est connue à l'avance) est toujours un bogue!

Pollux
: Voilà, après tout dépend de l'utilisation qu'on veut en faire. Si un petit programme plante quand on lui donne un nom de fichier de 200 caractères, ben c pas la mort parce qu'il fallait juste pas jouer au con.

Si un programme plante, c'est toujours un bogue.
En tout cas, cette remarque me laisse supposer pas mal de trucs sur la stabilité de GTools Compiler... Personnellement, vu comment tu programmes (ou du moins comment tu dis programmer), je ne laisserai pas ce truc même s'approcher de ma calculatrice.

Après, si on programme sur PC et qu'on veut faire un truc secure, faut commencer à faire gaffe, mais sur TI c pas super grave. Et on peut toujours rajouter des vérifications avec strlen...

C'est la moindre des choses à faire. Mais du coup, strncpy devient souvent plus simple.

Si un programme plante, c'est toujours un bogue. En tout cas, cette remarque me laisse supposer pas mal de trucs sur la stabilité de GTools Compiler...

Parceque tu es trop con pour savoir que les noms de 200 caractères n'existent pas sur TI ? Non. Donc aucun danger.

Personnellement, vu comment tu programmes (ou du moins comment tu dis programmer), je ne laisserai pas ce truc même s'approcher de ma calculatrice.

Pfff arrête ! tout le monde a compris depuis longtemps que tu hais GTC (pour des raisons incompréhensibles) et que c'est pas des bogues potentiels (utilisation très anormale) qui te freinent, mais ta fierté et ta jalousie, ta haine...

bon restons courtois les enfants, pas de sang dans ce topic (Thibaut...)

Thibaut, <SARCASM>c'est bien</SARCASM>, je vois que tu continues à raconter n'importe quoi. Je refuse d'utiliser des logiciels qui plantent sans arrêt, un point, c'est tout. Les logiciels de la TICT ne plantent pas, eux. Il y avait une possibilité d'overflow dans ttstart si on mettait plus d'une 40aine de caractères comme nom de variable, et ben il a été vu comme ce qu'il était: un bogue. Et il a été corrigé. Je suis les mêmes principes pour mes programmes à moi. C'est ça un programme stable, et je ne charge pas de programmes instables sur mes calculatrices.

Et Thibaut, je sais déjà que tu me détestes, pas la peine de me le montrer à chaque fois.

Et je sais aussi que tu es fanatique de GTools Compiler (amoureux de Pollux? ), pas la peine de me le montrer à chaque fois, ça non plus.

prochain post hostile l'un et l'autre -> kick.
on revient dans le sujet.

En tout cas je ne crois pas avoir vu un seul crash de GTC sur PC malgré le nb de progs que j'ai compilé, et comme les tailles de buffer sont les mêmes, ben c'est pareil on-calc. Après, on peut bien sûr choisir de ne pas le mettre sur sa calc pour des raisons idéologiques, mais ça c'est un autre problème

arf, post croisé

Kevin Kofler
:

liquid
: je ne suis aps d'accord, strncpy prend plus de place que strcpy dans un prgm et strcpy copie jusque rencontre du caractere '\0' donc ca ne doit a priori pas planter si on fait pas n'importe quoi

N'importe quoi. Utiliser strcpy sur une chaîne dont la longueur n'est pas connue à l'avance (ou plutôt dont aucune borne supérieure raisonnable pour la longueur n'est connue à l'avance) est toujours un bogue!

Un programmeur qui ne sait pas utiliser strcpy sans danger de plantage est un mauvais programmeur.

Pollux
: Voilà, après tout dépend de l'utilisation qu'on veut en faire. Si un petit programme plante quand on lui donne un nom de fichier de 200 caractères, ben c pas la mort parce qu'il fallait juste pas jouer au con.

Si un programme plante, c'est toujours un bogue.

Certes mais là n'est pas la question, si on sait a l'avance quel genre de chaines on va manipuler, utiliser strcpy est une reelle optimisation au programme.

Après, si on programme sur PC et qu'on veut faire un truc secure, faut commencer à faire gaffe, mais sur TI c pas super grave. Et on peut toujours rajouter des vérifications avec strlen...

C'est la moindre des choses à faire. Mais du coup, strncpy devient souvent plus simple.

Oui, mais je n'ai personnellement pas toujours besoin d'utiliser strlen quand je sais que les chaines que je manipule ne feront pas planter le programme.

Et es-tu sûr que tu réussis à compter correctement tes lettres? Je te signale que tu viens d'en mettre 2 de trop à "je manipule".

C'est marrant, il me semble me rappeler avoir dû corriger moi-même un certain frontend qui avait la curieuse propriété de planter sauvagement dès qu'on essayait de mettre plus de trois ou quatre options sur la ligne de commande... ceci à cause d'une utilisation *légèrement* dangereuse de strcopy/strcat

Ce n'est pas moi qui ai codé cette horreur! Je te remercie beaucoup de l'avoir corrigé.
J'ai d'ailleurs corrigé moi-même le tprbuilder. Dans ce cas, je n'ai pas utilisé ta méthode (vecteurs argv), mais une méthode plus portable (en pensant aussi à la version Win32): j'ai tout simplement remplacé tous les appels à strcat par des dynstrcat, dynstrcat étant une fonction qui appelle realloc et strcat.

ah merde, je me suis enflammé là