Discussion :

[Crackerz]

Bonsoir,

J'essaye de réecrirre la fonction memset en fonction de ce que me dis le man, cependant comment contrôler le fait que len ne dois pas être négative ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
void *my_memset(void *b, int c, size_t len)
{
	unsigned char	*s;
	size_t	         i;
 
	i = 0;
	s = (unsigned char*) b;
	while (i < len)
	{
		s[i] = (unsigned char)c;
		i++;
	}
	return (b);
}

Si j'essaye d'appeler la fonction comme ça my_memset(b,2,-1), (len négative) => segmentation fault. Je comprend parfaitement l'erreur, je sors des limites de ma variable s.
La fonction standard memset quand à elle gére bien ce cas puisqu'elle me renvoi : abort ...

Merci pour vos explications.

[Bktero]

Bonjour,

Tu n'as pas dû te renseigné correctement sur le type size_t. Ce type est normalement non-signé ; il en existe une version signée, ssize_t. (J'espère ne pas dire de bêtise, il est tard, la journée a été dure).

Ainsi, tu ne peux pas appeler ta fonction de cette manière sans que ton compilateur émette un warning, *sauf* si tu n'as pas activé les options d'usage pour la génération des warnings (-Wall avec gcc par exemple).

Tu ne sors pas des limites de s. -1 est simplement converti en valeur positive. Sans doute 0xFFFFFFFF sur une machine 32 bits car c'est la représentation de -1 en complément à 2. Je te laisse imaginer ce que fait ton code avec une telle valeur en entrée et pourquoi tu te choppes une erreur de segmentation.

Autres remarques :

• séparer déclarations et initialisations me semble contre-productif ici
• tu castes le pointeur void* en unsigned char* alors que tu souhaites mettre un int dedans. Pourquoi ? :((

[Crackerz]

Merci Bktero pour ta réponse ultra-rapide

Ainsi, tu ne peux pas appeler ta fonction de cette manière sans que ton compilateur émette un warning, *sauf* si tu n'as pas activé les options d'usage pour la génération des warnings (-Wall avec gcc par exemple).

Hum, je suis sous Mac, je compile ainsi : gcc -Wall -Werror -Wextra. Aucun warning, même lorsque j'utilise la fonction standard memset cela me renvoi un abord comme dit précédemment.

Tu ne sors pas des limites de s. -1 est simplement converti en valeur positive. Sans doute 0xFFFFFFFF sur une machine 32 bits car c'est la représentation de -1 en complément à 2. Je te laisse imaginer ce que fait ton code avec une telle valeur en entrée et pourquoi tu te choppes une erreur de segmentation.

C'est ce que j'appelle effectivement sortir de mon tableau, effectivement en prenant le complément à deux ma valeur deviens positif ( un très gros chiffre - je l'ai afficher ), ce qui m'amène à accéder à une case mémoire n'appartenant pas à ma variable s :s[GRAND NOMBRE] = (unsigned char)c; => segmentation fault

tu castes le pointeur void* en unsigned char* alors que tu souhaites mettre un int dedans. Pourquoi ? (

J'ai fais ainsi car le man me dit : "The memset() function writes len bytes of value c (converted to an unsigned char) to the string b."

Je pense que ma fonction est juste car j'ai comparer la standard avec la mienne, la seule différence réside dans le fait que lorsque j'ai une erreur segmentation fault, la standard répond : [1] 6644 abort ./a.out.

[Sve@r]

Bonjour

Bktero a bien trouvé le problème. Ton seg_fault vient du fait que -1 converti en size_t (donc probablement en unsigned long) devient 4 294 967 295 et que ta zone à remplir ne fait probablement pas cette taille

Mais pour répondre à ta question, si ta fonction ne stocke pas la valeur reçue dans un "signed" tu ne peux absolument pas détecter que t'as reçu un négatif. ssize_t ("signed size_t") peut convenir. D'ailleurs je ne pense pas que le memset d'origine (qui stocke lui-aussi la taille dans un size_t) détecte le négatif parce que si c'était le cas, tu n'aurais pas de "abort" (renvoyé par ton OS et non par la fonction). Surtout que chez-moi, ça me fait un segfault preuve qu'il détecte que dalle !!!

Autre chose: tu peux encore optimiser ta fonction en incrémentant directement le pointeur "s" plutôt que de taper dans s[i] et remplacer initialisation, while et incrément par un simple for (en fait tout tient dans le for qui n'aura alors aucun autre code)

PS: moi non plus je ne sais pas pourquoi memset (le vrai) demande lui-aussi un int alors qu'il sera stocké fatalement dans un tableau d'octets. Peut-être par soucis d'optimisation lors du passage de paramètres (calage sur les mots machine)...

PS2: tu ne dois jamais émettre une hypothèse sur un comportement indéterminé (comme par exemple dire que memset() détecte le négatif parce que tu as un abort). Un comportement indéterminé est exactement ce que le terme signifie, c'est à dire "non prévisible". Un coup tu peux avoir "abort", un autre "segfault" (comme chez-moi), un 3° tu peux même avoir ta fonction qui s'exécute correctement et qui ira remplir sans soucis 4 294 967 295 octets à partir de l'adresse reçue (sans soucis "immédiat" s'entend car il est plus que probable que dans ces 4 294 967 295 octets, certains sont utilisés par d'autres variables de ton programme et que la suite du programme s'en ressentira...)

[Crackerz]

Bonjour,

J'ai bien compris vos explications merci. Cependant mes programmes personnelle ne m'ont jamais renvoyé un abort, j'ai donc ( mal ) pensé que ces memset standard qui détecter le segfault, ça me rassure que ça ne soit pas le cas car je n'ai pas trouvé comment vu le type de len...
Quoi qu'il en soit merci, je vais prendre vos conseils pour l'optimisation

[Médinoc]

Je pense que j'ai une petite idée de la vérification pratiquée par memset:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
void *my_memset(void *b, int c, size_t len)
{
	unsigned char	*s;
	size_t	         i;
	uintptr_t bufferStart;
 
	bufferStart = (uintptr_t)b;
	assert((bufferStart + len) >=bufferStart);
 
	i = 0;
	s = (unsigned char*) b;
	while (i < len)
	{
		s[i] = (unsigned char)c;
		i++;
	}
	return (b);
}

Cela permet de vérifier que b+len ne cause pas d'overflow, et détectera donc un len "négatif".

[Bktero]

Merci Bktero pour ta réponse ultra-rapide

De rien

Hum, je suis sous Mac, je compile ainsi : gcc -Wall -Werror -Wextra. Aucun warning

J'ai mis du temps à le retrouver : -Wconversion. Il n'est pas dans -Wall ni dans -Wextra visiblement... Ta ligne de compilation est très bien sinon !

J'ai fais ainsi car le man me dit : "The memset() function writes len bytes of value c (converted to an unsigned char) to the string b."

http://linux.die.net/man/3/memset -->

The memset() function fills the first n bytes of the memory area pointed to by s with the constant byte c.

https://developer.apple.com/library/.../memset.3.html -->

The memset() function writes len bytes of value c (converted to an unsigned char) to the string b.

Hum hum....

En regardant la norme C99 (page 345) :

The memset function copies the value of c (converted to an unsigned char) into each of the first n characters of the object pointed to by s.

Par contre, je pense que cela sous-entend qu'il faut vérifier que l'entier rentre dans un char ? Que l'écriture est fait en plusieurs fois ? Je trouve cette description un peu étonnante.

@Médinoc : ça ne me parait pas déconnant. Faudrait regarder dans les libc comment c'est implémenté.

[Sve@r]

@Médinoc : ça ne me parait pas déconnant. Faudrait regarder dans les libc comment c'est implémenté.

Ben à moi si. Si la valeur passée est -1 alors len vaut 4 294 967 295 et alors (bufferStart + len) est bien supérieur à bufferStart. Donc l'assertion est toujours vérifiée. Et je vois mal une fonction de la libc détecter quelque chose d'incorrect mais ne rien faire et laisser l'OS se démerder tout seul par un abort ou un segfault.

Euh et puis en plus, mon gcc ne connait pas assert...

Cela permet de vérifier que b+len ne cause pas d'overflow

Même si la valeur passée est -4 294 967 295 ???

[Médinoc]

Si (size_t)-1 vaut 4294967295, alors c'est un système 32 bits.
Et dans un système 32 bits, bufferStart+4294967295 causera un overflow, et vaudra alors bufferStart-1!
Qui est inférieur à bufferStart.

PS: Un size_t ne peut pas valoir -4294967295 sur un système 32 bits.

PPS: Je ne prétends pas que la libc puisse détecter un débordement du buffer, loin de là, mais elle peut au moins détecter les débordements numériques (ou "tours de compteur").