bug PedroM : strncpy - Page 1

Bon je viens de batailler pour essayer de faire marcher F-Zero sur PedroM (tu m'avais dit que ca venait probablement de moi dans mon topic, et ben je crois plutôt le contraire ).
Donc j'ai traqué le bug jusqu'a arriver à en déduire que c'est la faute a strncpy.
J'ai fait un petit programme de test pour prouver tout ca

// C Source File
// Created 15/06/2005; 15:29:34

#include <tigcclib.h>

// Main Function
char buff[256];

void _main(void)
{
	const char chaine[] = "abc\def\ghi";
	char chaine2[256];
	
	clrscr();
	
	sprintf(buff,"%s", chaine);
	ST_helpMsg (buff);
	ngetchx();

	strncpy(chaine2, chaine, 3);
	
	sprintf(buff,"%s", chaine);
	ST_helpMsg (buff);
	ngetchx();


}

donc voila sous AMS on a comme résultat :
abc\def\ghi , appui sur enter
abc\def\ghi , appui sur enter
et ca quitte

et sous PedroM
abc\def\ghi , appui sur enter
abc\ , appui sur enter
et ca quitte

Donc on voit bien que PedroM modifie le parametre src de strncpy (alors qu'en plus il est déclaré en const), bref je sais pas si a avait été déjà trouvé (peut etre ca a a voir avec les \ dans la chaine aussi ?)

Voila c'est tout pour mon bug report

bon j'ai regardé le source de strncpy et je n'ai pas le niveau pour detecter d'ou viendrait le pb (mais en tout cas ca n'a rien a voir avec les \)

-

EDIT : cross, mais la correction d'orion est fausse

;char *strncpy (char *dest, const char *src, unsigned long maxlen); 
strncpy:
	move.l	4(a7),a0	; Dest 
	move.l	8(a7),a1	; Src
	move.l	12(a7),d1	; Len
\loop		move.b	(a1)+,(a0)+
		dbeq	d1,\loop
	clr.b	(a1)
	move.l	4(a7),a0	; Dest
	rts

Il suffit de remplacer
clr.b (a1)
par

  dbne d1,\padloop
  rts
\padloop
  clr.b (a0)+
  dbf d1,\padloop

-

tu vois pas la différence entre "x[i] = 0" et "memset(&x[i],0,n-i)"

-

bah nan, avant que j'édite y avait déjà toute la boucle, je faisais juste une itération de trop qd il fallait padder

-

ben oui, c'est bien ce que je dis, j'avais mis un "bne \quit" au lieu de "dbf d1,\padloop;rts" (d'ailleurs si on voulais optimiser en taille, ce qui serait plus logique, ce serait plutôt "bne \loop; subq.w #1,d1"), avec \quit juste à la sortie de padloop, mais ça change juste que je faisais une itération de trop qd je paddais, ce qui ne justifie pas du tout ton commentaire comme quoi ça ferait la même chose que x[i]=0

espèce de !mac va ^^

juste une question:
move.b (a1)+,(a0)+
dbeq d1,\loop

pouvez vous me dire quand (a1)!=(a0) ?

beq/bne ne testent pas l'égalité des deux dernières opérandes, mais la nullité du résultat de la dernière opération...

donc par exemple "cmp x,y; beq" teste si le resultat de cmp est nul, autrement dit si x-y est nul, autrement dit si x=y.
dans le cas de move, "move x,y; beq" test si le resultat de move est nul, autrement dit si y est nul (ou si x est nul, ça revient au même)

ok merci

Voici ce que j'utilise :

;char *strncpy (char *dest, const char *src, unsigned long maxlen); 
strncpy:
	move.l	4(a7),a0			; Dest 
	move.l	8(a7),a1			; Src
	move.l	12(a7),d1			; Len
\CopyLoop:	move.b	(a1)+,(a0)+
		beq.s	\EndOfString
		subq.l	#1,d1
		bne.s	\CopyLoop
\End:	clr.b	-(a0)		;  We have copied 'len' chars from src to dest. Null pad last one
	move.l	4(a7),a0	;  Return dest
	rts
	;; We must fill the last remaining chars with 0
\NullCopy:	clr.b	(a0)+
\EndOfString:	subq.l	#1,d1
		bne.s	\NullCopy
	bra.s	\End

Ca vous semble ok ?

Le test passe de LionelA passe avec.

Nan ta version est fausse aussi :

strncpy copies up to maxlen characters from src into dest, truncating or null-padding dest. The target string, dest, might not be null-terminated if the length of src is maxlen or more. Returns dest.

Mouais sinon pour les trucs de plus de 64ko effectivement ça pourrait être utile en théorie puisque pedrom supporte les handles de + de 64k, mais bon ^^

;char *strncpy (char *dest, const char *src, unsigned long maxlen);  
strncpy: 
	move.l	4(a7),a0			; Dest  
	move.l	8(a7),a1			; Src 
	move.l	12(a7),d1			; Len 
\CopyLoop:	move.b	(a1)+,(a0)+ 
		beq.s	\EndOfString 
		subq.l	#1,d1 
		bne.s	\CopyLoop 
\End: move.l	4(a7),a0	;  Return dest 
	rts 
	;; We must fill the last remaining chars with 0 
\NullCopy:	clr.b	(a0)+ 
\EndOfString:	subq.l	#1,d1 
		bne.s	\NullCopy 
	bra.s	\End 

Ok ?

hmm on peut encore optimiser en taille, par exemple on peut gagner 6 octets au chargement des paramètres :

  movem.l (a7),d0-d1/a0-a1
  exg.l d1,a1

et inverser a0 et a1 dans la suite, sauf pour la valeur de retour


mais sinon oui c bon j'ai l'impression ^^

Pas le temps de le faire.

vi ct juste pour te faire chier, si tu voulais optimiser pedrom à ce point-là y aurait BCP de boulot

<troll> c d'ailleurs pour ça que l'asm pur ça sux ^^

Tu n'as qu'a reporter tout ce que tu vois
Je corrigerai un jour

Pollux>beaucoup de boulots ou beaucoup de modifs ?

je vois pas vraiment la différence... enfin oui ça impliquerait bcp de modifs ^^

Pasque beaucoup de boulot n'implique pas forcément beaucoup de modif. Rien que vérifier que les modifs ne sont pas utils, c'est déjà beaucoup de boulot

oui oui, mais c'est pas du "boulot" de voir si y a des modifs à faire

sinon oui clairement si à peu près n'importe quelle fonction qui prend plus de 2 paramètres stkparm peut être optimisé en taille ça veut dire plein de modifs...