Lors de l'exécution, j'obtiens le message :

Ceci lors du premier rebouclage de la boucle While...
Je ne comprends pas pourquoi  
Visiblement il plante au premier malloc    
 
Merci pour votre aide
Froozen.

la ligne 13 est completement fausse

 
C'est mieux ?

oui !

Merci

"Salut.Bah.voilà.skoul"
 
ça fait 23 caractères

#         tutu = (char*)malloc(22*sizeof(char));
#         tutu = "Salut.Bah.voilà.skoul";
 
=>=>=>
 
tutu = strdup("Salut.Bah.voilà.skoul" );
 
 
#         titi = (char*)malloc(sizeof(tutu));
#
#         strcpy(titi, tutu)
 
=>=>=>=
 
titi = strdup(tutu);
 
 
jsais pas pkoi personne ne l'aime, ste fonction.

 
heuuuuuuuuuuuuu

si je te réponds, ça va te paraître évident
 
SPA STANDARD BORDEL

vas-y compte. et si t'es doué en algèbre, utilise l'opérateur sizeof (et sans parenthèses si possible)

Exemple 1: Taz ne sait pas compter  
T'aurais quand même pu tester

 
Bouuuh  
 
edit: et si on ajoute \0 on passe à 22, toujours pas 23

Ben avec les " ca fait 23
 
Autrement sérieusement je trouve 22 en comptant et sizeof("Salut.Bah.voilà.skoul" ) me dit 22 aussi.

et là je te retombe dessus illico
 
UTF-8 pawa !
les autres codages c'est de la merde
 

 
donc trust no one. Utilise sizeof/strlen et pas tes yeux.

Et tu crois que c'est en UTF-8 ici ?
 
De toute facon faut utiliser des wchar_t

 
[ finalement ça n'a rien à faire ici ! ]

 
 
PUISQUE CAI CA JE RENTRE CHEZ MA MERE §§

bonne ambiance

 
mais tout le monde s'en bas les burnes des standards, la portabilité c'est un mythe alacon et le type c'est un debutant qui s'en fout surement encore plus que moi (c'est dire)

toi tu ne sais pas ce qu'est l'UTF-8
 

non spa un mythe à la con, et autant pas se prendre les pieds dans le tapis dès le début. Plus sérieusement, tu prends par exemple un prof de fac, qui connait à peine strlen, alors si tu lui sors un strdup ... déjà il sait pas ce que c'est, et quand il va compilé sur son ouin-ouin, ça pas marcher.
 
glib pawa

moi je trouve ça très intéressant comme problème, et c'est même un sacré piège.

il parlait de ce qu'il a édité et qui se trouve dans la quote de krissebaika

Je savait que ca serait mal compris en fait je voulais dire que je préfère utiliser des wchar plutot que l'UTF-8 mais c'est sûr en UTF-8 on fait généralement plus d'éconnomie de caractères.

je comprends ce qui s'est passé ... c'est moi la petite merde prétentieuse ?

le problème, c'est pas les wchar_t ou des char. C'est ce qu'utilise ton éditeur, et comment ton compilateur gère les codages de caractères multi-octets.

Tu veux dire que certains compilateur font de l'UTF-8 avec des wchar_t, je pensait que c'était toujours l'UTF-16 ou 32 qui était utilisé.
 
Sinon je suis d'accord avec les char.

ça me semble évident, et même si c'était écrit sous la colère (raison très probable de l'édit) son coup de gueule n'est pas complètement infondé

 
Absolument, il semblerait que tu sois un etron qui, en plus d'etre fumant, soit aussi vantard

et invivable

+1

non je veux dire que par exemple la glib/GTK+/GNOME utilise l'UTF-8 partout avec des char, ça marche sans problème. Après pour wchar_t, c'est une histoire de compilateur ET bibliothèque. En C++, c'est actuellement très casse gueule par exemple.

c'est pas ma faute si aujourd'hui les débutants sont des baltringues

C'était juste une blague reprenant, de même que le génial krissebaika et afin de rendre hommage à ce méconnu génie, les termes originels de Mr Mala

Normal, sizeof retourne la taille (longueur, + 1 pour le 0)

Pas d'accord. Le langage C est défini par une norme qui représente le 'socle commun' (pour parler branché!). Il est AMA important, surtout quand on débute, de bien comprendre quel est le domaine commun du langage, et quelles sont les extensions.
 
D'autre part, la portabilité n'est pas un mythe. Cette bibliothèque est portable, et c'est du concret.  
 
http://mapage.noos.fr/emdel/clib.htm
 
Elle tourne sur  

• Intel x86 16-bit mode réel
• Intel x86 32-bit mode étendu
• Freescale (ex-Motorola) 68000
• Freescale PowerPC
• DSP Texas TMS320C54

et probablement d'autres plateformes, moyennant des adaptations minimes dans la poubelle 'sys.h'
 
Des bibliothèques portables, il en existe pas mal. Les gens qui les écrivement ne s'assoient pas sur les normes... Ils les connaissent, et ils savent comment écrire du code portable...
 
C'est un métier...
 
Ceci dit, évidemment, il est parfois utile d'utiliser des extensions, tout ce que je demande, c'est qu'elles servent à écrire la couche d'adaptation et qu'elles ne soient pas saupoudrées n'importe où dans le code applicatif... Ca s'appelle l'abstraction, et c'est une bonne chose...

Il me semble qu'en C99 le fait de prefixer ses fonctions de manière réservée (str*, to*...) -entre autre- amène un "comportement indéfini". Je prend le cas du préfixage de noms de fonction parce qu'il est très piègeux. Ca veut dire quoi concrétement "comportement indéfini"?

C'était déjà le cas en C90...

Qu'il peut arriver n'importe quoi. C'est un bug grave. La plupart des comportements indéfinis (Undefined Behaviour ou UB) ne sont pas détectable par l'analyse automatique du code. Leur detection reste donc du domaine des experts du C et doit être enseignée très tôt.
 
Les exemples les plus courants:
 

• débordement de tableau
• utilisation de gets()
• utilisation de scanf("%s", tableau_de_char) (idem gets())
• utilisation d'une variable non initialisée
• utilisation de fonctions variadics sans prototype
• types incompatibles
• utilisation des opérateurs logiques sur un type signé
• copie mémoire avec recouvrement (memcpy() vs memmove())
• paramètres d'une fonction hors limites

... les cas sont innombrables.
 
Le C n'est pas un langage de débutant en programmation.

 
En fait j'ai découvert ce truc de préfixage de fonctions il y a peu de temps, j'ignore si c'est un piège connu ou non (il est mentionné dans C unleashed acheté sur votre conseil, mais pas dans Expert C Programming (j'en suis à peu près sur)) à moins que je sois passé à côté.

'C Unleashed' est vraiment la référence ultime en matière de C 'intelligent'. Sa grande force est d'être un livre collégial écrit par les animateurs infatigables et inestimables de news:comp.lang.c et validée par le 'peer review', et non l'oeuvre solitaire d'un auteur obscur, aussi bon soit-il.
 
La FAQ de fclc est du même tonneau.
 
http://www.isty-info.uvsq.fr/~rumeau/fclc/

Il est excellent en effet, de part les qualités que vous avez énumérez et par la richesse des thèmes abordés (optimisation, algorithmes, speech processing, simulation...). Il est passionnant. C'est probablement le bouquin technique le mieux foutu que j'ai lu (bon en fait je l'ai pas encore fini). Dans une moindre mesure, les bouquins de Stevens sont aussi très bien foutus mais centrés sur Unix et pas très respectueux des standards (bien que Advanced Unix programming permet de mieux les comprendre), exit(0); direct en fin de main par exemple