Pourquoi utiliser bzero sur memset?

Dans un cours de programmation système que j'ai suivi ce semestre précédent, nous avons dû implémenter un client / serveur de base en C.Lors de l'initialisation des structs, like sock_addr_in, ou char buffers (que nous utilisions pour envoyer des données entre le client et le serveur) le professeur nous a demandé de les utiliser uniquement bzeroet de ne memsetpas les initialiser. Il n'a jamais expliqué pourquoi, et je suis curieux de savoir s'il y a une raison valable à cela?

Je vois ici: http://fdiv.net/2009/01/14/memset-vs-bzero-ultimate-showdown qui bzeroest plus efficace en raison du fait que la mémoire ne sera jamais remise à zéro, donc ce n'est pas doivent faire toute vérification supplémentaire qui memsetpourrait le faire. Cela ne semble pas nécessairement être une raison pour ne pas l'utiliser memsetpour la réinitialisation de la mémoire.

bzeroest considérée comme obsolète et n'est en outre pas une fonction C standard. Selon le manuel, il memsetest préférable bzeropour cette raison. Alors, pourquoi voudriez-vous encore utiliser bzeroplus memset? Juste pour les gains d'efficacité, ou est-ce quelque chose de plus? De même, quels sont les avantages de memsetsur bzeroqui en font l'option préférée de facto pour les programmes plus récents?

Je ne vois aucune raison de préférer bzeroplus memset.

memsetest une fonction C standard alors qu'elle bzeron'a jamais été une fonction standard C. La raison est probablement que vous pouvez obtenir exactement la même fonctionnalité en utilisant la memsetfonction.

En ce qui concerne maintenant l'efficacité, les compilateurs comme gccutilisent des implémentations intégrées pour memsetlesquelles basculent vers une implémentation particulière lorsqu'une constante 0est détectée. Idem glibclorsque les fonctions intégrées sont désactivées.

Je suppose que vous avez utilisé (ou que votre professeur a été influencé par) la programmation réseau UNIX de W. Richard Stevens. Il utilise bzerofréquemment à la place de memset, même dans l'édition la plus récente. Le livre est si populaire, je pense que c'est devenu un idiome dans la programmation réseau, c'est pourquoi vous le voyez toujours utilisé.

Je m'en tiendrai memsetsimplement parce qu'il bzeroest obsolète et réduit la portabilité. Je doute que vous voyiez des gains réels à utiliser l'un par rapport à l'autre.

Le seul avantage que je pense bzero()avoir sur la memset()mise à zéro de la mémoire est qu'il y a un risque réduit d'erreur.

Plus d'une fois, j'ai rencontré un bug qui ressemblait à:

memset(someobject, size_of_object, 0);    // clear object

Le compilateur ne se plaindra pas (bien que peut-être augmenter certains niveaux d'avertissement sur certains compilateurs) et l'effet sera que la mémoire n'est pas effacée. Parce que cela ne détruit pas l'objet - cela le laisse tranquille - il y a de bonnes chances que le bogue ne se manifeste pas en quoi que ce soit d'évident.

Le fait que ce bzero()ne soit pas standard est un irritant mineur. (FWIW, je ne serais pas surpris si la plupart des appels de fonction dans mes programmes ne sont pas standard; en fait, écrire de telles fonctions est un peu mon travail).

Dans un commentaire à une autre réponse ici, Aaron Newton a cité ce qui suit de Unix Network Programming, Volume 1, 3rd Edition par Stevens, et al., Section 1.2 (italiques ajoutés):

bzeron'est pas une fonction ANSI C. Il est dérivé du premier code de réseau Berkely. Néanmoins, nous l'utilisons dans tout le texte, au lieu de la memsetfonction ANSI C , car il bzeroest plus facile à retenir (avec seulement deux arguments) que memset(avec trois arguments). Presque tous les fournisseurs qui prennent en charge l'API sockets fournissent également bzero, et sinon, nous fournissons une définition de macro dans notre en- unp.htête.

En effet, l'auteur de TCPv3 [TCP / IP Illustrated, Volume 3 - Stevens 1996] a commis l'erreur de permuter les deuxième et troisième arguments memseten 10 occurrences lors de la première impression . Le compilateur AC ne peut pas intercepter cette erreur car les deux arguments sont du même type. (En fait, le deuxième argument est un intet le troisième est size_t, qui est généralement un unsigned int, mais les valeurs spécifiées, respectivement 0 et 16, sont toujours acceptables pour l'autre type d'argument.) L'appel à memsettoujours fonctionnait, car seul un peu de fonctions de socket exigent en fait que les 8 derniers octets d'une structure d'adresse de socket Internet soient mis à 0. Néanmoins, c'était une erreur, et une qui pourrait être évitée en utilisant bzero, car l'échange des deux arguments en bzerosera toujours intercepté par le compilateur C si des prototypes de fonction sont utilisés.

Je pense également que la grande majorité des appels à memset()sont à zéro mémoire, alors pourquoi ne pas utiliser une API adaptée à ce cas d'utilisation?

Un inconvénient possible bzero()est que les compilateurs pourraient être plus susceptibles d'optimiser memcpy()parce que c'est standard et qu'ils pourraient donc être écrits pour le reconnaître. Cependant, gardez à l'esprit qu'un code correct est toujours meilleur qu'un code incorrect optimisé. Dans la plupart des cas, l'utilisation bzero()n'entraînera pas un impact notable sur les performances de votre programme, et cela bzero()peut être une macro ou une fonction en ligne qui se développe en memcpy().

Je voulais parler de l'argument bzero vs memset. Installez ltrace puis comparez ce qu'il fait sous le capot. Sous Linux avec libc6 (2.19-0ubuntu6.6), les appels effectués sont exactement les mêmes (via ltrace ./test123):

long m[] = {0}; // generates a call to memset(0x7fffefa28238, '\0', 8)
int* p;
bzero(&p, 4);   // generates a call to memset(0x7fffefa28230, '\0', 4)

On m'a dit qu'à moins de travailler dans les entrailles profondes de la libc ou de n'importe quel nombre d'interfaces noyau / syscall, je n'ai pas à m'inquiéter pour eux. Tout ce dont je dois m'inquiéter, c'est que l'appel satisfasse à l'exigence de remise à zéro du tampon. D'autres ont mentionné lequel est préférable à l'autre, je vais donc m'arrêter ici.

Vous ne devriez probablement pas utiliser bzero, ce n'est pas vraiment du C standard, c'était une chose POSIX.

Et notez que le mot «était» - il était obsolète dans POSIX.1-2001 et supprimé dans POSIX.1-2008 par respect pour memset, il est donc préférable d'utiliser la fonction C standard.

Pour la fonction memset, le deuxième argument est an intet le troisième argument est size_t,

void *memset(void *s, int c, size_t n);

qui est typiquement un unsigned int, mais si les valeurs comme, 0 and 16pour le deuxième et le troisième argument respectivement sont entrées dans le mauvais ordre comme 16 et 0 alors, un tel appel à memset peut toujours fonctionner, mais ne fera rien. Parce que le nombre d'octets à initialiser est spécifié comme 0.

void bzero(void *s, size_t n)

Une telle erreur peut être évitée en utilisant bzero, car la permutation des deux arguments en bzero sera toujours interceptée par le compilateur C si des prototypes de fonction sont utilisés.

En bref: memset nécessitent alors plus d'opérations d'assemblage bzero.

Voici la source: http://fdiv.net/2009/01/14/memset-vs-bzero-ultimate-showdown

Ayez-le comme vous le souhaitez. :-)

#ifndef bzero
#define bzero(d,n) memset((d),0,(n))
#endif

Notez que:

1. L'original bzerone renvoie rien, memsetretourne le pointeur void ( d). Cela peut être résolu en ajoutant le transtypage à void dans la définition.
2. #ifndef bzerone vous empêche pas de masquer la fonction d'origine même si elle existe. Il teste l'existence d'une macro. Cela peut causer beaucoup de confusion.
3. Il est impossible de créer un pointeur de fonction vers une macro. Lorsque vous utilisez bzerovia des pointeurs de fonction, cela ne fonctionnera pas.

memset prend 3 paramètres, bzero prend 2 en mémoire contraint ce paramètre supplémentaire prendrait 4 octets de plus et la plupart du temps, il sera utilisé pour tout mettre à 0