(je suis débutant en c) je ne vois d'instruction pour boucler

bpascal123

02/12/2009 à 00:45

On Dec 2, 12:35 am, ""
wrote:

merci sami
mais je ne sais pas si ces personnes peuvent comprendre
pascal

d'ajouter que ces personnes s'approprient la décision d'apprendre le
langage c comme autodidacte, même si c'est une erreur c'est aussi un
challenge, je ne vois pas ce que je fais de mal et en quoi ça les
dérange pour détourner à ce point le sujet de discussion alors pour
continuer ici, il me reste 2 solutions poster sous un autre id ou
changer pour comp.lang.c

candide

02/12/2009 à 01:07

a écrit :

d'ajouter que ces personnes s'approprient la décision d'apprendre le
langage c comme autodidacte, même si c'est une erreur c'est aussi un
challenge,

Ce n'est pas une erreur, je pense qu'ici beaucoup de gens ont appris le
C sans avoir reçu de cours de C. Sinon, c'est un challenge parce que si
t'es pas génial comme c'est mon cas, la doc est super mal faite et
qu'elle te fait perdre un temps pas possible.

je ne vois pas ce que je fais de mal et en quoi ça les
dérange

Tu ne fais rien de mal, tu ne déranges pas et même tu redonnes de
l'activité au forum !!

Le problème c'est que tu as une façon selon moi très inorganisée -- et
parfois confuse -- de poser tes questions, donnant l'impression de ne
pas discerner l'essentiel de l'accessoire. Tout ceci est à replacer dans
un contexte où ton projet personnel d'apprentissage est très fluctuant
(C, ASM, algos, web).

Et que par exemple tu veuilles faire du C et ne pas apprendre les
fonction est proprement sidérant.

pour détourner à ce point le sujet de discussion

Mais c'est pas contre toi qu'on le fait, ça s'est toujours fait sur
usenet (enfin j'ai l'impression), il n'y pas de modérateur, on discute,
on s'empaille, c'est du folklore ya certainement même des extérieurs qui
comptent les points ou viennent souffler sur les braises voire vous
cracher dessus.

lors pour
continuer ici, il me reste 2 solutions poster sous un autre id ou

:)))

Déjà, je me demande si t'en est pas à ton deuxième pseudo.

changer pour comp.lang.c

Oui, j'y ai déjà lu de tes messages. A mon avis ça va pas changer ton
problème.

Marc Boyer

02/12/2009 à 10:15

Le 01-12-2009, Samuel Devulder a écrit :

candide a écrit :

Non mais un code qui contient un UB ne peut rien prouver.

De toute façon, si on suit la norme, alors tous les programmes
contiennent des UB (ne serait-ce qu'à cause des overflows arithmétiques
ou des I/O non vérifiées si j'ai bien compris l'état d'esprit des thread
précédent) et donc on ne peut rien prouver à rien et tout ces threads
sont stériles.

Je ne sais pas si tu as compris un "état d'esprit", mais tu as
quan même raté des choses importantes.

D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main,

Le pire problème, c'est surtout le programme qui "tombe en marche",
le code qui va tourner en mode debug et planter une fois optimisé,
ou qui va tourner sur Linux/x86 et qui va planter sur le proc cible...

et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main.

Là, on parle d'attitudes, c'est pas vraiment du C. Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Le 01-12-2009, Samuel Devulder <samuel-dot-devulder@geensys.com> a écrit :

candide a écrit :

Non mais un code qui contient un UB ne peut rien prouver.

De toute façon, si on suit la norme, alors tous les programmes
contiennent des UB (ne serait-ce qu'à cause des overflows arithmétiques
ou des I/O non vérifiées si j'ai bien compris l'état d'esprit des thread
précédent) et donc on ne peut rien prouver à rien et tout ces threads
sont stériles.

Je ne sais pas si tu as compris un "état d'esprit", mais tu as
quan même raté des choses importantes.

D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main,

Le pire problème, c'est surtout le programme qui "tombe en marche",
le code qui va tourner en mode debug et planter une fois optimisé,
ou qui va tourner sur Linux/x86 et qui va planter sur le proc cible...

et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main.

Là, on parle d'attitudes, c'est pas vraiment du C. Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Vous avez filtré cet utilisateur ! Consultez son message

Le 01-12-2009, Samuel Devulder a écrit :

candide a écrit :

Non mais un code qui contient un UB ne peut rien prouver.

De toute façon, si on suit la norme, alors tous les programmes
contiennent des UB (ne serait-ce qu'à cause des overflows arithmétiques
ou des I/O non vérifiées si j'ai bien compris l'état d'esprit des thread
précédent) et donc on ne peut rien prouver à rien et tout ces threads
sont stériles.

Je ne sais pas si tu as compris un "état d'esprit", mais tu as
quan même raté des choses importantes.

D'un coté il y a les codeurs qui font des trucs (qui marchent ou
plantent peu importe) et demandent des coups de main,

Le pire problème, c'est surtout le programme qui "tombe en marche",
le code qui va tourner en mode debug et planter une fois optimisé,
ou qui va tourner sur Linux/x86 et qui va planter sur le proc cible...

et de l'autre il y
a les avocats ou les curés qui ne cherchent qu'à décourager les premiers
en arguant que de toute façon leur programme est non conforme aux
aspects +/- obscures de à la norme, et qu'en conséquence ils finirons en
enfer et ne peuvent prétendre à aucun coup de main.

Là, on parle d'attitudes, c'est pas vraiment du C. Est-ce que dire
qu'on programme ne respecte pas la norme c'est décourager les gens ?
A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Perso je préfère faire des trucs qui marchent que de passer ma vie à
trouver pourquoi selon la norme le truc ne devrait pas marcher alors
qu'il marche effectivement dans les faits.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Senhon

02/12/2009 à 11:01

"Marc Espie" a écrit dans le message de groupe de
discussion : hf3u67$138q$

In article <4b157a26$0$12471$,
candide wrote:
Samuel Devulder a écrit :

Tiens une girouette courageuse qui vient de tourner avec le vent !

Sinon, le degré zéro : ça marche chez moi donc c'est bon ! La caricature
te conduit à raconter n'importe quoi.

Quelqu'un trouvait recemment que j'avais ete vulgaire a ton egard.
Je l'incite a regarder ton comportement. Tes petites piques incessantes
et mesquines finissent par lasser fortement...
Fais gaffe, tu es au bord du *plonk*.

Je comprends que Candide puisse agacer.
Ce qu'il dit est à ranger dans le même ordre que l'excellentissime Antoine
Leca.

Lorsque le débat devient trop tatillon à mon goût ( comme dans le cas
présent, avec l'UB) , je laisse tomber le fil, en y jetant un oeil de temps
en temps. C'est pas plus dur que ça.
Mais vouloir l'empêcher ( surtout qu'il est en charte ) de s'exprimer juste
parce que le sujet ne t'intéresse plus, c'est ... inqualifiable.

Si Candide disait n'importe quoi, je te comprendrais, mais ce qu'il dit est
juste, sauf à quelques exceptions près, et encore de ce que je crois me
souvenir, il reconnait, alors, s'être trompé. Tout ça dans le respect de
l'interlocuteur !

De tout évidence Candide est un esprit brillant, de tout évidence cela te
gênes, et s'est dommage.
Tu es sûrement du même acabit que lui, mais l'agressivité parasite ton
propos.

espie

02/12/2009 à 15:49

In article <4b163afa$0$30487$,
Senhon wrote:

Si Candide disait n'importe quoi, je te comprendrais, mais ce qu'il dit est
juste, sauf à quelques exceptions près, et encore de ce que je crois me
souvenir, il reconnait, alors, s'être trompé. Tout ça dans le respect de
l'interlocuteur !

Il y a n'importe quoi et n'importe quoi. Quand ce qu'il dit est du
n'importe quoi en surface, et que ca va paumer un debutant, ca me
derange fortement.

De tout évidence Candide est un esprit brillant, de tout évidence cela te
gênes, et s'est dommage.

De mon point de vue, Candide n'est pas tres brillant. Je trouve meme
qu'il pete plus haut que son cul, comme on dit par chez moi.

Il lui arrive de ne pas rapporter n'importe quoi, mais sa facon un
peu absurde de toujours titiller les gens et de vouloir tout ramenej
a la norme independamment de la realite finit par lasser.

Tu es sûrement du même acabit que lui, mais l'agressivité parasite ton
propos.

Je prefere etre directement agressif et clair que de garder des choses
par devers moi et de parasiter la discussion tout le temps...

Pierre Maurette

02/12/2009 à 16:39

Marc Espie, le 02/12/2009 a écrit :

[...]

qu'il pete plus haut que son cul, comme on dit par chez moi.

Chez moi, la bonne ville de Sète, /Île *Singulière*/ s'il en est, on
dit plutôt "il ne faut pas poéter plus haut que son cul". Sète est
riche comme peu d'autres lieux de poètes et autres /trobadors/,
puisqu'à la francophonie elle alla jusqu'à offrir Eve Angéli.
Google ne peut me renseigner sur l'origine de cette expression, La
Norme non plus soit dit en passant, comme quoi...
A l'oreille, je l'attribuerais volontiers à Nougaro, mais peut-être
est-elle simplement issue de la sagesse populaire, du domaine public,
du GNU-GPL de l'expression savoureuse ?

--
Pierre Maurette

Pierre Maurette

02/12/2009 à 17:35

Marc Espie, le 01/12/2009 a écrit :

[...]

Je sais pas, j'ai jamais lu de Proust, et de ce qu'on m'en a dit, ca fait
pas envie ;-)

Bien entendu je ne connais de l'oeuvre de Marcel Proust que quelques
/bonnes feuilles/. Pas désagréable, pas idiot du tout, mais ça semble
quand même interminable. Proust est moins connu pour son oeuvre que
pour les gags qu'il génère, "J'ai tout lu Proust", "Actuellement je
RElis /la recherche/", etc.
Je ne vois pas trop de pont à établir entre la production de Marcel et
l'informatique, encore que certains exégètes proustiens me rappellent
les dérives infinies de tel ou tel obsédé de La Norme.
En revanche, deux auteurs au moins me rappellent mon apprentissage
laborieux. Je pense à Albert Cohen (pour /Belle du seigneur/) et James
Joyce (pour /Ulysse/). Je ne suis jamais parvenu au bout d'aucun des
deux romans cités. Jeune, j'y revenais, plein de motivation, tous les
deux ou trois ans. J'ai fini par jeter l'éponge. Pour Joyce, je me suis
consolé avec /Dubliners/.
Le rapport avec l'informatique ? C'est les Regex et Emacs. Pour les
Regex, c'est foutu, à chaque fois que je dois utiliser, je repars à
zéro, c'est atrocement laborieux, et je suis infoutu de relire mon
code. Pour Emacs, c'est un peu moins grave. J'ai trouvé mon
/Dubliners/, c'est Vim. Et puis entre-temps j'ai initié une love story
avec Eclipse.

--
Pierre Maurette

Wykaaa

02/12/2009 à 20:45

Pierre Maurette a écrit :

Marc Espie, le 02/12/2009 a écrit :

[...]

qu'il pete plus haut que son cul, comme on dit par chez moi.

Chez moi, la bonne ville de Sète, /Île *Singulière*/ s'il en est, on dit
plutôt "il ne faut pas poéter plus haut que son cul". Sète est riche
comme peu d'autres lieux de poètes et autres /trobadors/, puisqu'à la
francophonie elle alla jusqu'à offrir Eve Angéli.
Google ne peut me renseigner sur l'origine de cette expression, La Norme
non plus soit dit en passant, comme quoi...
A l'oreille, je l'attribuerais volontiers à Nougaro, mais peut-être
est-elle simplement issue de la sagesse populaire, du domaine public, du
GNU-GPL de l'expression savoureuse ?

Tu n'as pas cherché bien longtemps et tu as considérablement vieilli
Nougaro :-)
http://www.expressio.fr/expressions/peter-plus-haut-que-son-cul.php

Pierre Maurette

02/12/2009 à 20:53

Wykaaa, le 02/12/2009 a écrit :

Pierre Maurette a écrit :
Marc Espie, le 02/12/2009 a écrit :

[...]

qu'il pete plus haut que son cul, comme on dit par chez moi.

Chez moi, la bonne ville de Sète, /Île *Singulière*/ s'il en est, on dit
plutôt "il ne faut pas poéter plus haut que son cul". Sète est riche comme
peu d'autres lieux de poètes et autres /trobadors/, puisqu'à la
francophonie elle alla jusqu'à offrir Eve Angéli.
Google ne peut me renseigner sur l'origine de cette expression, La Norme
non plus soit dit en passant, comme quoi...
A l'oreille, je l'attribuerais volontiers à Nougaro, mais peut-être
est-elle simplement issue de la sagesse populaire, du domaine public, du
GNU-GPL de l'expression savoureuse ?

Tu n'as pas cherché bien longtemps et tu as considérablement vieilli Nougaro
:-)
http://www.expressio.fr/expressions/peter-plus-haut-que-son-cul.php

J'ai un peu de mal à vous suivre. Je parlais de /poéter/ et non de
/péter/. Prout.

--
Pierre Maurette

Samuel Devulder

02/12/2009 à 21:28

Marc Boyer a écrit :

Là, on parle d'attitudes, c'est pas vraiment du C.

C'est juste.

Est-ce que dire

qu'on programme ne respecte pas la norme c'est décourager les gens ?

En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.

Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.

L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.

A l'inverse il y a des posts qui concernent typiquement la norme, et
encore d'autres où pour trancher entre deux interprétations il faut
avoir recours à ce que dit la norme, et là je n'ai rien contre la citer
fort à propos. Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).

A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.

Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)

_____
[*] Un outil sympa dans le domaine de la vérif de code: cbmc
(http://www.cprover.org/cbmc/). Je ne sais pas s'il est très cité par
ici, mais il est pas mal: il sort des contre exemples pour les assert()
qu'on a placé dans le code. Ca peut aider à voir pourquoi le compilo,
splint ou l'utilisateur final ne sont pas contents.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Sisi, mais dans ce cas ca se débug, comme au 1er jour, comme si on
trouvait un bug nouveau. L'avantage est qu'on sait ce qui a changé est à
l'interface entre le coeur du prog et l'OS. Ca limite les recherches.

Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit. Tous les progs ont des bugs ou sont
utilisés dans des environnements changeants. On est donc amené à faire
évoluer un code toute sa vie durant. Ca n'est pas pour rien que ce qui
est vendu c'est pas tellement un logiciel tout nu mais la maintenance
autour. On raconte dans le métier qu'un prog sans bug est juste un prog
mort (ou non utilisé, c'est synonyme).

De plus de nos jour tout change, tout est codé à l'arrache (en C ou
autre chose), les APIs tierces sont sorties non stabilisées ou sont
incompatibles les unes les autres, avec une compatibilité ascendante
toute relative: les OS encore pire (souvent compatible au niveau ABI,
tout en ayant un comportement différent) et au final changer de compilo,
de librairie ou d'OS revient quasi systematiquement à ré-implémenter les
couches d'abstractions entre le coeur du code et les bibliothèques
externes. C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.

sam.

Marc Boyer a écrit :

Là, on parle d'attitudes, c'est pas vraiment du C.

C'est juste.

Est-ce que dire

qu'on programme ne respecte pas la norme c'est décourager les gens ?

En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.

Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.

L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.

A l'inverse il y a des posts qui concernent typiquement la norme, et
encore d'autres où pour trancher entre deux interprétations il faut
avoir recours à ce que dit la norme, et là je n'ai rien contre la citer
fort à propos. Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).

A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.

Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)

_____
[*] Un outil sympa dans le domaine de la vérif de code: cbmc
(http://www.cprover.org/cbmc/). Je ne sais pas s'il est très cité par
ici, mais il est pas mal: il sort des contre exemples pour les assert()
qu'on a placé dans le code. Ca peut aider à voir pourquoi le compilo,
splint ou l'utilisateur final ne sont pas contents.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Sisi, mais dans ce cas ca se débug, comme au 1er jour, comme si on
trouvait un bug nouveau. L'avantage est qu'on sait ce qui a changé est à
l'interface entre le coeur du prog et l'OS. Ca limite les recherches.

Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit. Tous les progs ont des bugs ou sont
utilisés dans des environnements changeants. On est donc amené à faire
évoluer un code toute sa vie durant. Ca n'est pas pour rien que ce qui
est vendu c'est pas tellement un logiciel tout nu mais la maintenance
autour. On raconte dans le métier qu'un prog sans bug est juste un prog
mort (ou non utilisé, c'est synonyme).

De plus de nos jour tout change, tout est codé à l'arrache (en C ou
autre chose), les APIs tierces sont sorties non stabilisées ou sont
incompatibles les unes les autres, avec une compatibilité ascendante
toute relative: les OS encore pire (souvent compatible au niveau ABI,
tout en ayant un comportement différent) et au final changer de compilo,
de librairie ou d'OS revient quasi systematiquement à ré-implémenter les
couches d'abstractions entre le coeur du code et les bibliothèques
externes. C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.

sam.

Vous avez filtré cet utilisateur ! Consultez son message

Marc Boyer a écrit :

Là, on parle d'attitudes, c'est pas vraiment du C.

C'est juste.

Est-ce que dire

qu'on programme ne respecte pas la norme c'est décourager les gens ?

En tout cas, sortir la norme quand c'est hors de propos est plutôt une
mauvaise idée vis a vis du problème de l'OP.

Ainsi quand quelqu'un énonce avoir des problèmes avec son implémentation
d'un truc équivalent à strstr() et qu'on commence à lui dire sorti la
norme parce que ceci ou cela au niveau des I/O alors que cela n'a
strictement, mais strictement rien à voir avec le soucis d'origine, je
trouve cela affligeant et propre à décourager ceux qui viennent chercher
des infos sur le NG.

L'OP vient chercher une explication à un défaut dans son code/snippet et
on lui sort des trucs qui n'ont rien a voir avec son pb, c'est pas
génial comme attitude. Sortir la norme à ce moment là est
particulièrement hors-sujet à mon avis.

A l'inverse il y a des posts qui concernent typiquement la norme, et
encore d'autres où pour trancher entre deux interprétations il faut
avoir recours à ce que dit la norme, et là je n'ai rien contre la citer
fort à propos. Le mieux étant bien entendu d'expliquer ce qu'elle
raconte plutôt que de recopier "in extenso" le paragraphe en anglais
sans le traduire (hierarchie fr.* pourtant).

A toi de voir. Quoi qu'il en soit, que le code suivant fonctionne
avec gcc en mode debug me semble une bétise.

int sum( int val[], size_t size ){
int lsum;
for( size_t i= 0 ; i < size ; ++i )
lsum+= val[i];
return lsum;
}

Ca dépend de ce que t'entends par marcher. Normalement si le code
marche, personne ne postera ici pour s'en plaindre.

Quant à la variable non initialisée, le moindre compilo sort un warning,
donc on est averti que ca peut ne pas marcher (même si ca marche parce
que le prologue de la fonction a utilisé un registre qui vaut 0 et qui
est réutilisé plus tard pour la variable lsum). De toute façon je
recommande toujours une passe dans un lint/splint et autres qa-c quand
le code semble marcher[*]. Ensuite on corrige jusqu'a ce qu'il n'y ait
plus de warnings ni de grognement de gcc/lint/splint/qac.. A ce moment
là le code ne fait plus ce qui était prévu (il est correct, mais faux
car ne rempli plus le CdC), on re-corrige, on rejoue les tests, en cycle
et a un moment ca se stabilise et on est heureux: le travail est fini,
on peut sortir le produit et faire la recette :)

_____
[*] Un outil sympa dans le domaine de la vérif de code: cbmc
(http://www.cprover.org/cbmc/). Je ne sais pas s'il est très cité par
ici, mais il est pas mal: il sort des contre exemples pour les assert()
qu'on a placé dans le code. Ca peut aider à voir pourquoi le compilo,
splint ou l'utilisateur final ne sont pas contents.

T'as jamais eu de code qui tourne plus parce que la version du compilo
a changé ? Jamais utilisé un paquetage qui est sensé marché avec bidule22.3
et qui marche plus avec bidule22.4 ? Jamais été sans une société qui
décide que SunOS n'est plus une cible pérenne et qu'il faut porter
le code sur Linux ?

Sisi, mais dans ce cas ca se débug, comme au 1er jour, comme si on
trouvait un bug nouveau. L'avantage est qu'on sait ce qui a changé est à
l'interface entre le coeur du prog et l'OS. Ca limite les recherches.

Il y a très peu de gens qui croient encore qu'un code source ne doit
plus évoluer une fois écrit. Tous les progs ont des bugs ou sont
utilisés dans des environnements changeants. On est donc amené à faire
évoluer un code toute sa vie durant. Ca n'est pas pour rien que ce qui
est vendu c'est pas tellement un logiciel tout nu mais la maintenance
autour. On raconte dans le métier qu'un prog sans bug est juste un prog
mort (ou non utilisé, c'est synonyme).

De plus de nos jour tout change, tout est codé à l'arrache (en C ou
autre chose), les APIs tierces sont sorties non stabilisées ou sont
incompatibles les unes les autres, avec une compatibilité ascendante
toute relative: les OS encore pire (souvent compatible au niveau ABI,
tout en ayant un comportement différent) et au final changer de compilo,
de librairie ou d'OS revient quasi systematiquement à ré-implémenter les
couches d'abstractions entre le coeur du code et les bibliothèques
externes. C'est chiant, mais c'est la vie. A ce niveau là, avoir choisi
un découpage de son logiciel de sorte à faciliter les portages, aide
beaucoup à la maintenance plus tard.

sam.

(je suis débutant en c) je ne vois d'instruction pour boucler

10 réponses

Veuillez sélectionner un problème