Discussion :

[nanocode]

merci diogene je test

edit: plus de warning, mais erreur de segmentation a l'execution, pas de sequence affichée..

merci a tous pour votre aide c'est vraiment cool

[diogene]

plus de warning, mais erreur de segmentation a l'execution, pas de sequence affichée..

merci a tous pour votre aide c'est vraiment cool

c'est vraiment cool ???? erreur de segmentation !!!! vraiment tu es facile à satisfaire
Il faudrait voir le code en l'état où il est actuellement pour faire le point

[Corentor]

Tu transmets à ta fonction l'adresse du tableau arn.
Dans ta fonction, le contenu du tableau est mis à jour.
Ce que tu renvoies est l'adresse du tableau arn (qui n'a pas changé dans ta fonction que tu aies modifié ou non le tableau).

Même si l'adresse n'a pas changé, les valeurs du tableau, elles, ont bien été modifiées et tu peux les exploiter avec la valeur de arn déclarée dans la fonction main.

Pour l'explication du 21, il faut savoir qu'en C, la chaîne littérale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"GAATGCGTGATGCGTGAATT"

est équivalente au tableau de caractères :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{ 'G', 'A', 'A', ... , 'A', 'T', 'T', '\0' }

Le compilateur rajoute toujours un caractère nul en fin de chaîne, donc la longueur réellement occupée par la chaîne est toujours supérieure de 1 à la longueur réellement affichée.

[nanocode]

merci corentor, tes explications assurent
je vais essayer de me depatouiller avec tout ca!

[nanocode]

ca y j ai ca marche, merci infiniment, mon erreur de segmentation c'etait à cause de "%c\n%c\n" au lieu de "%s\n%s\n"
corentor, j ai enlevé le return
encore merci

[Corentor]

Retourner arn n'est pas forcément une mauvaise idée puisqu'elle permet ce type d'écriture à un coût minime

Code :
printf("%s\n%s\n", seq, adn2arn(seq, arn, lSeq));

Je suis d'accord sur ce point.
La valeur de retour a un côté pratique pour l'appel depuis des fonctions.

Je modère quand même ce que j'ai dit. Le type d'écriture ci-dessus peut être dangereux, s'il est mal maîtrisé. On ne teste pas la valeur de retour de la fonction avant de l'utiliser, et la conception d'une fonction ne devrait pas encourager cela. Que va-t-il se passer la séquence d'adn en entrée contient des bases inattendues (autres que A, T, G, C) par exemple (dans le cas présent, je reconnais que c'est sans objet puisque la fonction ne gère de toute façon pas les erreurs et laisse les bases invalides telles quelles). On pourrait envisager de renvoyer un pointeur NULL, ou de mettre le premier caractère du tableau arn à '\0' (chaîne vide).

Dans ce cas, il est nécessaire de tester la sortie de la fonction avant de l'utiliser dans un appel (soit la valeur de retour, soit le contenu du tableau de sortie arn), et on perd le bénéfice de l'écriture condensée ci-dessus.

Attention, je n'affirme pas qu'il faut éviter à tout prix ce type de conception, mais le bénéfice d'une écriture condensée ne devrait jamais être l'argument d'un choix de conception.