2016-08-17 2 views
2

Les pièces dsPic30/33 et 18E/F produiront des erreurs de mémoire si des accès 16 bits sont effectués en mémoire sur des adresses impaires. Lorsque vous allouez de la mémoire heap en utilisant malloc(), l'adresse de retour est-elle garantie pour être alignée sur un mot? (c'est-à-dire pair)Est-ce que malloc() sous Microchip XC16 est garanti pour produire des adresses alignées sur un mot?

malloc, vous vous en souviendrez, prend un argument en octets, pas en mots.

La documentation que j'ai été en mesure de trouver (manuel de référence de la bibliothèque d'outils linguistiques 16 bits 50001456J.pdf) est muette sur ce problème. Edit: Je dois ajouter que je n'ai jamais reçu que des adresses paires (alignées sur un mot) de malloc(), donc tout fonctionne bien jusqu'à maintenant. Néanmoins, mon code causera un piège si jamais je reçois une adresse étrange (parce que je fais des choses comme ((uint16_t *)foo)[3] = 20000;). Par conséquent, je veux être sûr que même les adresses sont toujours retournées par malloc().

+0

Est-ce que la langue a un type qui effectue des accès 16 bits? Quelque chose comme 'some_type foo; foo = 3; 'où' = 'fait-il un accès 16 bits? Si c'est le cas, 'malloc' * doit * fonctionner. –

+0

@DavidSchwartz bien il est possible que l'implémentation soit buggée –

+0

La documentation ne vous aiderait pas si c'était un bug. Les bogues sont généralement non documentés. S'il a un vrai type 16 bits, alors malloc doit donner un pointeur légal à un. –

Répondre

2

Le standard C oblige malloc() à renvoyer un pointeur satisfaisant toute exigence d'alignement de la mémoire imposée par l'implémentation pour tout objet pouvant entrer dans l'allocation. Si un compilateur devait traiter tous les accès mémoire d'une manière qui fonctionnerait indépendamment de l'alignement, l'implémentation de malloc() pourrait renvoyer des pointeurs avec un alignement arbitraire. De nombreuses implémentations retourneront en fait des pointeurs alignés sur des multiples de 2, 4 ou 8 octets même si l'alignement requis n'est pas trop grossier, car cela évite d'avoir à traiter des zones d'espace libre plus petites, mais à moins que une implémentation promet explicitement qu'il ne faut pas s'attendre à ce qu'un tel comportement ne change pas.

0

Il suffit d'éviter malloc. De MISRA/C 2004:

Règle 20.4 (obligatoire): allocation de mémoire de tas dynamique ne doit pas être utilisé. [non spécifié 19; Undefined 91, 92; Mise en œuvre 69; Koenig 32] Ceci empêche l'utilisation des fonctions calloc, malloc, realloc et free. Il existe toute une gamme de comportements non spécifiés, indéfinis et définis par l'implémentation associés avec allocation de mémoire dynamique, ainsi qu'un certain nombre d'autres pièges potentiels. Dynamic tas allocation de mémoire peut conduire à des fuites de mémoire, l'incohérence des données, l'épuisement de la mémoire, comportement non déterministe . Notez que certaines implémentations peuvent utiliser l'allocation dynamique de mémoire dynamique pour implémenter d'autres fonctions (par exemple, des fonctions dans la bibliothèque string.h). Si tel est le cas, ces fonctions doivent également être évitées.

Si vous savez que vous n'aurez pas besoin de stocker plus de 100 entiers, déclarez simplement un tableau avec une taille de 128 éléments (par exemple).

+0

"La bonne chose à propos des normes est qu'il y a tellement de choix." -Andrew Tanenbaum Le problème avec cela est quand avoir, par exemple, le code d'un tampon qui est utilisé à plusieurs endroits dans un projet. Certaines utilisations nécessitent un petit tampon, d'autres nécessitent un tampon plus grand. L'interface peut être grandement simplifiée en utilisant l'allocation dynamique. De nombreuses applications critiques pour la sécurité ont des règles comme "Pas de malloc après l'initialisation" ou "pas de démarrage au démarrage de malloc". –

1

Microchip a confirmé via son équipe assistance que XC16 malloc() et realloc() retournent toujours des adresses paires.