compilateur C sur yosemite

[rougevin]

Bonjour à tous

Ayant depuis peu une nouvelle machine sous OSX 10.10.1 (ce que je regrette vivement : je n'ai vu jusqu'à présent que des inconvénients par rapport à snow leopard (10.6), mais passons... ) et voulant recompiler un assez gros programme en C qui passait les doigts dans le nez sous 10.6 et 10.4 (et ptêt meme avant), j'ai la mauvaise surprise d'avoir à l'exécution un "Abort trap: 6", et dans la console : "detected source and destination buffer overlap"

Je ne pourrais pas jurer qu'il n'y ait pas dans ce code des memcpy() ou des strcpy() avec des sources et des destinations qui se marchent un peu sur les pieds (ca fait un bail que je l'ai écrit), mais si c'est le cas c'est certainement voulu et géré puisque ce programme marchait parfaitement sur OSX10.6 et OSX10.4

Je suppose donc que le compilateur place dans le code des outils de vérification au moment de l'execution ?

Et si oui y a-t-il un moyen de désactiver cela ? Je programme en C et non en C++ et j'entend rester le maître à bord dans mes programmes, non mais sans blague !

 

[Larme]

Potentiellement un buffer qui est dorénavant trop petit.
Avec les appareils qui deviennent de plus en plus puissant et avec plus de mémoire, il est possible qu'une donnée que tu utilisais soit plus grande que le buffer nécessaire d'antan.
Exemple tout bête :
Tu veux récupérer une adresse IP, auparavant, un buffer assez petit était suffisant, mais maintenant avec l'IPV6...

 

[Nyx0uf]

Et si oui y a-t-il un moyen de désactiver cela ? Je programme en C et non en C++ et j'entend rester le maître à bord dans mes programmes, non mais sans blague !

Ca me fait marrer ce genre de remarques, les compilateurs sont de plus en plus puissants et permettent de trouver des erreurs de programmation beaucoup plus facilement qu'avant, je ne vois pas pourquoi cracher dessus. Si ton prog crash l'idée logique serait de le corriger non..?

Après si tu veux un autre compilo que clang, tu peux installer gcc via homebrew par exemple.

 

[rougevin]

Mon programme ne crachait pas : l'erreur était due a un strcpy() pour lequel en effet il y avait un overlap -parfaitement conscient et voulu- entre les buffers d'entrée et de sortie. La preuve en est qu'en remplacant strcpy() par :

void mystrcpy(char *s1,char *s2)
{while ((*s1++ = *s2++)) ; }

tout est rentré dans l'ordre.

Je ne sais pas d'ailleurs si c'est le compilateur ou les librairies standart du C qui se permettent ces "contrôles" non prévus par K&R, je ne dis pas que ce soit intrinséquement une mauvaise chose du reste (en effet ca peut éviter des crahs à un programmeur distrait), mais je renvendique juste le droit de les désactiver si je ne veux pas qu'ils soient faits pour des raisons qui me sont propres (recherche de performances, ou autres). Voila...

 

[osnola]

Bonjour,

Mon programme ne crachait pas : l'erreur était due a un strcpy() pour lequel en effet il y avait un overlap -parfaitement conscient et voulu- entre les buffers d'entrée et de sortie. La preuve en est qu'en remplacant strcpy() par :
....Je ne sais pas d'ailleurs si c'est le compilateur ou les librairies standart du C qui se permettent ces "contrôles" non prévus par K&R, je ne dis pas que ce soit intrinséquement une mauvaise chose du reste (en effet ca peut éviter des crahs à un programmeur distrait), mais je renvendique juste le droit de les désactiver si je ne veux pas qu'ils soient faits pour des raisons qui me sont propres (recherche de performances, ou autres). Voila...

au moins depuis la norme C99 (http://busybox.net/~landley/c99-draft.html#7.21.2.3 ), il est bien indiqué que dans le cas d'un overlap, le comportement de cette fonction est indéfini ( donc autant provoquer une erreur )...

Note: Dans ce cas, il faudrait regarder du côte de memmove http://en.cppreference.com/w/c/string/byte/memmove qui devrait permettre l'overlapping....

 

[Mboum]

Bonjour, exactement: memmove et memset (l'on manipule la mémoire et non des chaînes de caractères ici) ; normalement on pointe la différence entre les deux (ce qui aujourd'hui n'est plus vrai, c'est souvent un alias) pour cette raison: la première permettant l'overlapping.

Quant aux functions de string, elles sont maintenant conformes au ```standard ; c'est le __check emit de la libc ; parce que bien écrite ; qui émet une "exception" ; la vérification ce fait lors du runtime ; c'est pour cela que cela crash`` ; de toutes les façons de nos jours strcpy n'est qu'un alias de strncpy.

En tous les cas, nous voyons ici que ce n'est pas un problème de compileur```

1- un problème de développeur (assez borné, je dois dire qui n'admet pas s'être trompé ).

2- le choix des développeurs de l'OS d'avoir un ring de protection dans le user-space qui soit standard strict, cela fait partie de la mention UNIX-certified.