Reprise du message précédent :
sais pas.
je vois pas l'interet par rapport à l'avoir dans le segment de donnée...

je m'interresse bcp a la structure des PE, c pour ca c détails m'interressent (c vrai qd on code des app on sen cogne completement)

Le tableau est initialisé par un élément solidairement et uniformément constant, c'est clair.

Chacun de ces chars pourrait provenir d'une variable ou d'un appel de fonction.
La constance éventuelle n'est connue qu'après examen de tous les éléments.
 
Donc, c'est simplement une mauvaise optimisation.
 
Quoi qu'il en soit, c'est bien une variable locale, chaque appel de fonction génère bien sa propre copie.

La structure des PE ? Les virus, quoi!  

non pas forcément ... pour faire un compilateur par exemple, tu dois dois savoir comment est écrit un .exe non ?
 
fo pas croire que tout se qui se rapproche du système, c pour les virus !!!

Je crois que tu perds ton temps à essayer de te justifier... ils n'ont pas l'air de vouloir te croire.
 
(oubliez pas qu'il reste des bogues à trouver)

ouais mais qd mm, tlm me dit ca alors que c'est faux, c'est lourd à la fin ...

Nan mais c'est bon je te crois mais c'est juste que je voyais pas d'autres utilités envisageables ( écrire un compilo ca me parait un peu ardu )  
 
Mais si c'est juste pour la connaissance de la théorie alors pourquoi pas
 
edit : personnelement la connaissance du format PE ne m'a pas encore servi a autre chose

pour l'instant ca ne ma pas été tres utile non plus, mais j'm bien essayer de comprendre comment fonctionnent les choses

et bin c mort ici ??? plus de bogues ? zut alors

Tricheur !
Tu ne connais pas toi-même la réponse...
STP supprime ton post.
 
[B]Solution n° 24:[/B]

Il ne faut pas d'espace entre le nom de macro et la parenthèse ouvrante.
 
Vous êtes vraiment mous... ça n'intéresse personne ?
Remarque, du code bogué, on en fait bien assez comme ça sans se forcer.

si si si moi ca m'interresse de chercher (qd je c ke les gens connaissent la solution ) mais chui pas un expert en débogage ...

au fait ca fait quoi #t ?

#t transforme l'argument de macro t en "chaîne littérale", avec guillemets et séquences d'échappements si nécessaire.

 
 
[B]Solution n° 25:[/B]

Les noms commençant par "_" sont réservés par le standard.

ok, d'accord, merci

Trouvez les 10 bogues ! (n° 19 à 28)
 
(je c pas si a été déjà dit)
 
dans

 
func n'a pas de "return type", il me semble que par defaut c un int, mais ca me parait pas tres standard ...
 
et puis aussi l'espace avant les parenthèses

Oui, bravo ! (enfin quelqu'un qui réagit)
 
[B]Solution n° 26:[/B]

Cette fonction a un type de retour int implicite, or elle ne renvoie rien.
Et de toutes façon, le type implicite n'a plus cours, ni pour les constantes, ni pour les fonctions.
C'est donc une double erreur.
Et puisqu'on est en C, levons toute ambiguïté sur les arguments attendus:

Je n'ai pas trouvé de réponse franche pour savoir si le pseudo argument "void" est nécessaire pour une telle définition. Quelqu'un sait ?
 
Pour l'espace, ça ne pose pas de problème. Il n'y a que pour la définition d'une macro-fonction que c'est important.
 
 
Rappelons le code coupable, corrigé des bogues déjà trouvés.
Fichier bogues.c

Il en reste 3 à découvrir.

Pour le void, mes souvenirs sont que en C il faut le mettre et qu'en C++ il ne faut pas. Bien sur, vu que la pluspart des compilateurs C font aussi C++ et vice versa, en général ca passe bien.

c plus claire comme ca je cherche ...

"sdtlib.h" vaut mieux pas mettre <stdlib.h> comme pour celui du dessus ? (si l'utilisateur en fait un aussi, ca sera le sien et pas le standard)
 
vu qu'il y a 2 guillemets, ca compte pour 2 bogues ?

atta atta atta ... encore 1 il me semble :
 

 
en fait le 1er if sans guillemets me turlupine ... le else va-t-il d'appliquer au 1er if ou au 2eme ? si c au 1er le mess d'erreur na rien a voir.
 
et sinon, il me semble en avoir trouver un autre :
 

 
va s'executer mm si malloc a échouer, donc free va essayer de libérer la mémoire mm si elle a pas été allouée

Fichier bogues.c

 
Le do  while ne devrait pas etre un while?

il me semble que ceci est déprécié
 

En C actuel:

Si un prototype a déjà été donné, "void func(){" est acceptable.
Sinon, c'est là que ça devient flou...

J'ai eu plusieurs avis divergents, et compétents bien que pas certains de leur affirmations... question en suspens.
 
Admirez la subtile compliquation et inutilité du problème...
Source: http://www.isty-info.uvsq.fr/~rume [...] 9.html#q_1
 
En C++, le prototypage est obligatoire, et (void) implicite, plus de problème.
 
 

À l'if immédiatement précédent, donc pas de problème.
Le "};" d'origine terminait la série de if et rendait le else orphelin.
Je me suis permis de ne pas mettre d'accolades au premier if car le if-else suivant constitue une seule grosse expression (statement).
Il va de soi que ce n'est pas recommandé dans du vrai code.
 

piégacon© !
Dans ce cas, malloc renvoie NULL, et free(NULL) est une opération nulle permise.
 
Le "stdlib", c'est un oubli.
 
 

Tu chauffes... t'es pas loin... cherche mieux.
 
 

Sur quel aspect ?
Au dernières nouvelles, tout marche et n'a pas de raison d'être mis aux oubliettes.

ben j'ai dit "il me semble"

[B]Solution n° 27:[/B]
scanf("%s"... s'attend à recevoir un argument char*, et reçoit un void*.
Cela n'est pas pareil, des pointeurs de type différent peuvent être de tailles différentes, ou tout simplement incompatibles.
Voir Recommended C Style and Coding Standards, rubrique "Portability".
 
Ordinairement, le compilateur voit l'argument attendu par la fonction grâce à son protoptype, et convertit le pointeur, ou en C++ donne un message d'erreur si ce n'est pas possible.
Seulement, scanf est une fonction à liste d'argument variable, les arguments au-delà du premier correspondent à "...", et les srcupules du compilateur s'arrêtent là.
 
Donc, il faut caster les arguments de printf ou scanf s'ils ne sont pas du bon type:

 
Je ne comprends pas, dans ta derniere correction ton buf est declare en tant que char *.

Je suis navré, j'ai corrigé ceci à tort en re-postant le code.

[B]Solution n° 28:[/B]

Les deux vont lire et écrire 32 caractères.
Quelle différence ? %s s'arrête sur les blancs. Mais encore ?
%s écrit une chaîne C, et va donc écrire un dernier et éventuellement 33ème caractère: '\0'. Écrasement de mémoire !
C'est d'autant plus insidieux qu'il peut passer inapperçu, si cet octet écrasé est le poids fort d'une variable voisine du buffer et qu'il vaut 0 de toutes façon, ou si cette variable est elle-même remplie par scanf après-coup.
 
Une belle petite boulette qui attendra le moment propice pour exploser.

[B]Solution n° 29:[/B]

Ce code souffre de la maladie du Pascal.
En Pascal, end-of-file est vrai quand il n'y a plus rien à lire.
En C, feof n'est vrai qu'une fois qu'on a tenté de lire alors qu'il n'y a plus rien à lire.
Bref, trop tard, c'est un voyant qui s'allume après le crash, et cette boucle fait un dernier tour de trop, le scanf échouant.
 
C'est bien sur valable pour les fichiers comme pour la console, pour feof comme pour le non-standard eof.
La solution est d'utiliser la lecture comme test de fin:

 
J'espère que ce voyage au pays des emmerdes vous a plus.
Restez attentif, le prochain départ est pour bientôt !

C'etait tres interressant mais je ne suis pas d'accord avec ton analyse:
Le vrai "criminel" dans cette affaire est le do { } while()
En effet,  
 
 

 
 
Marche parfaitement bien.  
Bon je pinaille un peu et je comprends que tu voulais nous montrer une subtilite toute autre (que je ne connaissais pas d'ailleurs )
En tout cas ce reservoir a bugs etait tres joli.

Non, non !
feof ne sera vrai que lorqu'une lecture aura effectivement échoué, la tournure de la boucle n'y change rien.
Le eof de Pascal, lui, est vrai quand la prochaine lecture échouera.
 
Vous en reprendrez bien un petit ?
 
[B]Trouvez le bogue n°30 ![/B]

Solution n°30 :
 
scanf ("%f", &d);
 
 
typique

sauf que y en a 2 bugs,ce n'est pas "%f" mais "%lf" pour les double (et "%Lf" pour les long double)

J'avais oublié de mettre '&', désolé.
 
Bravo à Taz@PPC qui ne s'est pas laissé distraire.
 
[B]Solution n° 30:[/B]

Mais alors, comment écrit-on un float ?
Comme un double.
Dans la partie variable d'une liste d'arguments, les types sont convertis selon les règles ancestrales du C.
Un float est automatiqement transformé en double.
De la même façon, un char est transformé en int. "%i" ou "%c" ne servent qu'à changer l'interprétation.
short, par contre, n'est pas altéré.

[B]Trouvez les bogues n°31 et 32 ![/B]
Ce code n'est pas de mon invention, c'est un extrait authentique.

Il y a aussi 6 défauts (environ, selon la façon de compter).

+ on ne teste si os et ns sont des valeurs valides (>0, je conseille l'emploi des types unsigned dès qu'on manipule des entiers strictement positifs, c'est cela de moins a vérifier, oublions un peu notre paresse)
+ on ne teste pas le bon fonctionnement de malloc, qui doit renvoie NULL en cas d'échec (ou si son argument est 0)
+ les cast sont inutiles
+ on ne sait pas si buf a été alloué avec malloc. s'il s'agit d'un simple tableau, booom
+ pour le 2eme appel à memcpy, si ns>os , re-boom, il faut donc utiliser os comme argument
+ fuite de mémoire: on ne libère pas temp
+ et evidemment void*temp et void*buf ou il manque un espace
 
 
7  
 
* tout ce code est inutile, realloc fait tres bien le boulot.
* l'appel malloc+memset(0) doit etre remplacer par un appel a calloc
 
et qu'on ne vienne pas me dire qu'il faut caster la valeur de retour de malloc, sinon vous allez voir pourquoi je m'appelle Taz

Attends... mettons de l'ordre:
 
Bogues

31) Effectivement, on risque de lire de la mémoire non-allouée. Mais la solution n'est pas aussi simple !
 

32) Ouaip.
 

33) Oui. Pourquoi on a tendance à oublier ça ?
 
Ah là là ! Laissez deux bogues seuls et ils font un petit...
 
 
Défauts dangereux

1) Affirmatif (je n'y avais pas pensé).
 
 
Stupidités

2) Yop !
 

3) Oui oui. Réécrire les fonctions standard est un formidable moyen de faire des bogues.
 

4) Commment ? Tu voudrais utiliser des fonctions standard ?
 
 
Fausses alertes

-> Ça n'est pas détectable, pas avec des moyens standard en tout cas.
 

-> C'est certes moche, mais tout à fait correct.
 
 
Disons qu'il reste à trouver:
2 stupidités dispendieuses
2 pinaillages affectant l'utilisateur

certes mais je n'ai jamais vu de fonction qui désalloue comme ca.

ben je sais plus quoi ca doit etre trivial: je sais jsute que si l'allocation du nouveau buf echoue, et bien on a tout perdu! en supposant que toutes les instructions précédentes ont fonctionnées, on ferait bien de retourner temp.
 
mais alors pres, je crois que tu pinailles vraiment la
 
 
+ y a 2 l a Reallocate  
+ le memset(0) peut avoir un effet désastreux avec des types autre qu'entiers et conduit à des représantions invalides (pas 0.0 en tout cas) ou à des trap representations

Si le but est de mimer le comportement de realloc, il faut aussi penser a faire un simple malloc dans le cas ou buf vaut NULL ( donc pas alloué avant l'appel )
Et si nc vaut 0; il faut faire un free sur buf